微服务是现在互联网的一个热点,谈到微服务,可能要说两个人,这两个人对微服务的架构定义有深远的影响,一个是马丁福勒(Martin Fowler),另外一个是Netflix的架构总监。
微服务概念
马丁福勒在14年的时候在他的博客上写了一篇很长的博文来介绍微服务架构,里面提到了微服务的核心特点要有
微服务架构只是一种架构风格,每种架构都有自己的架构特点。
早先单块架构,所有的应用在一个应用中,微服务把这些一个个的应用拆出来。
微服务是运行在独立的进程中的,现在的容器本质上也是一个进程,以进程的方式横向扩展微服务
原先服务间通信的时候,可能有重量级的通信方式如soup协议,但是微服务主张轻量级的协议比如说HTTP,减少消息格式。
基于业务能力构建,比如说商品服务,订单服务,这些业务能力去构建微服务
每个团队可独立的部署微服务,这样迭代就会比较快
早先是由独立的架构团队来统一技术站,统一存储方式,微服务就不一样,主张每个团队根据自己的技术选择技术栈。
松耦合,面向服务架构,有界上下文
在分布式系统中,当每个团队有独立的数据源的时候,又会带来什么样的挑战呢?
微服务权衡
微服务虽然是现在的一个热点,但是作为架构师来说,我们要非常清晰的了解它的优势和挑战。因为架构最重要的一个职责就是权衡,那么微服务有哪些利和弊呢
优势:
强模块化边界,模块化是一个很重要的方面,最开始用类做,后面用组件,类库的方式,微服务则是用服务的方式做模块化。不用像jar包一样做分享,而是通过调用的方式
可独立部署,每个团队根据自己的需要去开发,部署。单块应用可能需要很多团队一起有一些协同开销
技术多样性,每个团队可以根据自己的需要,业务的实际情况,选择最优的技术栈,有的团队擅长Java,有的擅长NodeJs,当然技术栈不要太多就是了
劣势:
分布式的复杂性,服务太多,一般的开发人员,团队都没法理解系统到底是怎么样工作的
最终一致性,每个团队都有自己的数据拷贝,有可能出现数据不一致的问题
运维复杂性,需要很多的服务,这个时候系统的可靠性,稳定性都有挑战的
测试复杂性,现在再去测试的话,功能在各个团队的,需要做联调,测试的复杂性就很高
微服务有利也有弊,微服务带来的复杂性,对运维的挑战是很大的,那么要如何应对这些挑战呢?
微服务引入
企业应该在什么时候引入微服务,这个是有讲究的。
单体应用,复杂性不高的时候,单体的效率会比较高,但是当项目复杂度不断的升高的时候,单体的效率则越来越低
微服务如果最开始就用微服务的话,生产力反而会比较低
单体与微服务曲线的交叉点的时候,就是引入微服务的时候。这个点需要架构师去综合的考虑,一般在团队到达100人的时候,就很需要引入微服务了。
有的人在一开始设计的时候就倾向于走向微服务,这个其实并不推荐,很难去把控拆分服务的边界。而且风险会比较高,很多时候我们单块优先,先用单块应用,随着业务不断的推进,规模不断扩展,这个时候再去进行微服务化。根据需要一个个的把相关模块拆出来。
有些架构师的观点觉得架构是设计出来的,有的架构师觉得架构是演进出来的。这个自行思考吧
是否适合微服务
康威法则:设计系统的架构受制于产生这些设计的组织的沟通结构。
那么什么样的组织架构更适合微服务呢?传统企业里面一般开发的流程流动方式为:都是按照明确的职能进行划分的
产品团队
用户体验
研发团队
测试团队
...
DBA团队
运维团队
这样的团队划分需要多次的协调,每一个团队都要进行沟通协调,成本比较高,反馈也比较慢。在微服务下则需要一些跨职能的团队,每个团队内部都有专家,用户,研发,测试等等,这些人围绕在微服务周围进行处理。
一个团队的规模大致12个人左右,亚马逊的CTO曾经说过:
谁构建,谁运行,谁负责
这样则要求微服务的团队内部能形成闭环,这个时候就能更好更快的响应业务的需求。微服务架构本质上是一种组织架构的重组。
最后
这里我们从微服务的概念开始引入,然后讨论了微服务的优缺点,以及企业在何时去引入微服务才是合适的,最后说了下微服务团队的特点。
后续我们再讲微服务的具体实施,项目的架构细节
参考
注:
本文独家发布自金蝶云社区
推荐阅读