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

0

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

你可能感兴趣的

载入中...