超哥是来自Amazon的顶级的架构师，经历了Amazon整个向微服务架构迁移的过程，以及向serverless的演化过程，有着极其丰富的经验，年过40，一直站在技术的最前沿，始终保持对技术的执着追求和热情，是名副其实的技术大牛，能与之一起工作，荣幸之至！今天超哥给我们分享的主题《microservice & serverless》，是超哥实际工作经验的一些分享，也为公司架构的演化提供了新的思路和指导。
microservice（微服务）这个可能是这些年最火的一种架构设计了，频繁地出现在各种技术大会上，各大互联网巨头纷纷向这种架构演化，很多小的互联网公司也往这些概念上去靠，大有一种不做微服务就要落伍的趋势。事实上，很多对于微服务的理解比较粗浅，盲目的微服务化甚至会带来更多的负面影响。
目前Amazon内部运行着超过2w过微服务，但是这些微服务并不是凭空产生的，在这之前，运行的服务都是超大的单体服务，但是随着业务的发展，这种服务在整个研发的pipeline（设计→研发→编译→测试→发布→部署→运维）中都出现了一些问题。设计阶段，老的单体服务会给我们带来一些技术限制，比如有些技术只有python语言的实现，但是我们的服务使用java开发，这样我们不得不拿出一个更复杂的设计去解决类似的问题；研发阶段，随着开发人数越来越多，代码冲突的问题越来越多，我们不得不花更多的时间去做这种无趣又没有什么意义的事情；编译阶段，越来越多的依赖很容易造成版本冲突，不同的版本也会引发兼容性的问题，而这种问题如果在运行时才暴露出来可能会造成严重业务影响；部署阶段，很多的特性打包在一起发布，特性越多，出问题的概率也就越大；而最致命的是运维阶段没有回滚方案，一次上线中可能包含很多的特性，而其中任何一条特性的bug就需要回滚，然后可能有些特性需要变更数据格式，新特性能向前兼容老的数据格式，但是回滚后却无法处理新的数据格式，因此无法回滚……就是在这样的背景下，Amazon开始朝微服务的架构演化。
微服务摆脱了单体服务技术的束缚，可以自由地根据业务的特点，选择最适合的技术去实现自己的服务；将一个大的开发流程拆成了很多个小的独立的开发流程，彼此之间不在相互依赖，大大缩短了项目周期；代码冲突的问题也得到了很好的改善；每次发布的特性很少，每天都能发布，而且能做到快速回滚。真正做到，持续集成，持续交付，敏捷开发。
微服务架构同时也带来了一些新的问题。相比与单体服务，微服务的架构数据的传输依赖于rpc的调用，这个调用会带来一些额外的网络耗时，这种耗时往往需要业务上面去考虑是否能容忍，这种rpc的调用收到网络环境的影响，失败是很正常事情，因此需要失败重试机制，于是代码里面到处都充斥着失败重试的冗余代码，影响代码的可读性，更糟糕的是会有雪崩效应，当某个底层服务出现问题时，比如响应时间过长，或者无法访问，这种影响会层层传递到上层，最终导致整个业务系统挂掉；在测试上面也会变得更加困难，之前都在一个实例里面，现在一个服务依赖很多其他的微服务，测试的时候都需要去mock，日志也会分布在不同的服务下面，问题排查比较困难；此外，数据分布在不同的微服务上，在数据一致性上也会有些问题。所以在进行微服务设计的时候也要特别注意这些额外的负面影响，封装重试逻辑，引入熔断和限流机制，统一的日志收集方式。
serverless（无服务器）架构可能是为了让devOps从繁复的运维工作中解放出来的全新架构，最大的特点是整个系统基于AWS提供的各种服务，能够做到自动的拓展以及按流量计费，不再需要人力去维护，大大提高了效率，同时按真实流量的计费对成本也有可能会有优化。而Fass架构，把业务需求封装在一个函数内部，开发人员只需要关注自己的业务逻辑，然后通过网页提交就能完成上线。我在想，当这些技术真正成熟和普及的时候，可能每个普通人，随便花点时间学点python，也能做出一个的服务，而那个时候，我的价值又是什么！？
转载请注明出处
本文链接：http://hatlonely.github.io/20...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。