微服务架构核心原创
金蝶云社区-艾贺521
艾贺521
3人赞赏了该文章 1,082次浏览 未经作者许可,禁止转载编辑于2019年05月08日 15:51:12


微服务是现在互联网的一个热点,谈到微服务,可能要说两个人,这两个人对微服务的架构定义有深远的影响,一个是马丁福勒(Martin Fowler),另外一个是Netflix的架构总监。


微服务概念

马丁福勒在14年的时候在他的博客上写了一篇很长的博文来介绍微服务架构,里面提到了微服务的核心特点要有

image.png

微服务架构只是一种架构风格,每种架构都有自己的架构特点。



早先单块架构,所有的应用在一个应用中,微服务把这些一个个的应用拆出来。

微服务是运行在独立的进程中的,现在的容器本质上也是一个进程,以进程的方式横向扩展微服务

原先服务间通信的时候,可能有重量级的通信方式如soup协议,但是微服务主张轻量级的协议比如说HTTP,减少消息格式。

基于业务能力构建,比如说商品服务,订单服务,这些业务能力去构建微服务

每个团队可独立的部署微服务,这样迭代就会比较快

早先是由独立的架构团队来统一技术站,统一存储方式,微服务就不一样,主张每个团队根据自己的技术选择技术栈。



松耦合,面向服务架构,有界上下文


在分布式系统中,当每个团队有独立的数据源的时候,又会带来什么样的挑战呢?


微服务权衡

微服务虽然是现在的一个热点,但是作为架构师来说,我们要非常清晰的了解它的优势和挑战。因为架构最重要的一个职责就是权衡,那么微服务有哪些利和弊呢


优势:

  • 强模块化边界,模块化是一个很重要的方面,最开始用类做,后面用组件,类库的方式,微服务则是用服务的方式做模块化。不用像jar包一样做分享,而是通过调用的方式

  • 可独立部署,每个团队根据自己的需要去开发,部署。单块应用可能需要很多团队一起有一些协同开销

  • 技术多样性,每个团队可以根据自己的需要,业务的实际情况,选择最优的技术栈,有的团队擅长Java,有的擅长NodeJs,当然技术栈不要太多就是了


劣势:

  • 分布式的复杂性,服务太多,一般的开发人员,团队都没法理解系统到底是怎么样工作的

  • 最终一致性,每个团队都有自己的数据拷贝,有可能出现数据不一致的问题

  • 运维复杂性,需要很多的服务,这个时候系统的可靠性,稳定性都有挑战的

  • 测试复杂性,现在再去测试的话,功能在各个团队的,需要做联调,测试的复杂性就很高


微服务有利也有弊,微服务带来的复杂性,对运维的挑战是很大的,那么要如何应对这些挑战呢?


微服务引入

企业应该在什么时候引入微服务,这个是有讲究的。


  • 单体应用,复杂性不高的时候,单体的效率会比较高,但是当项目复杂度不断的升高的时候,单体的效率则越来越低

  • 微服务如果最开始就用微服务的话,生产力反而会比较低

image.png


单体与微服务曲线的交叉点的时候,就是引入微服务的时候。这个点需要架构师去综合的考虑,一般在团队到达100人的时候,就很需要引入微服务了。


有的人在一开始设计的时候就倾向于走向微服务,这个其实并不推荐,很难去把控拆分服务的边界。而且风险会比较高,很多时候我们单块优先,先用单块应用,随着业务不断的推进,规模不断扩展,这个时候再去进行微服务化。根据需要一个个的把相关模块拆出来。


有些架构师的观点觉得架构是设计出来的,有的架构师觉得架构是演进出来的。这个自行思考吧



是否适合微服务

康威法则:设计系统的架构受制于产生这些设计的组织的沟通结构。


那么什么样的组织架构更适合微服务呢?传统企业里面一般开发的流程流动方式为:都是按照明确的职能进行划分的

  • 产品团队

  • 用户体验

  • 研发团队

  • 测试团队

  • ...

  • DBA团队

  • 运维团队


这样的团队划分需要多次的协调,每一个团队都要进行沟通协调,成本比较高,反馈也比较慢。在微服务下则需要一些跨职能的团队,每个团队内部都有专家,用户,研发,测试等等,这些人围绕在微服务周围进行处理。


一个团队的规模大致12个人左右,亚马逊的CTO曾经说过:

谁构建,谁运行,谁负责


这样则要求微服务的团队内部能形成闭环,这个时候就能更好更快的响应业务的需求。微服务架构本质上是一种组织架构的重组。


最后

这里我们从微服务的概念开始引入,然后讨论了微服务的优缺点,以及企业在何时去引入微服务才是合适的,最后说了下微服务团队的特点。

后续我们再讲微服务的具体实施,项目的架构细节


参考


注:

本文独家发布自金蝶云社区


图标赞 3
3人点赞
还没有人点赞,快来当第一个点赞的人吧!
图标打赏
0人打赏
还没有人打赏,快来当第一个打赏的人吧!