《microservice & serverless》by蔡超的一点感想

超哥是来自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...