架构演进之“微服务架构”

  

架构演进之“微服务架构

  

"为什么要搞“微服务架构”?这也是我们当初讨论的聚焦点。现在天天把“微服务”挂在嘴边的人很多,但是有多少人真正深入思考过“为什么”,我认为可能不多。

  

于是我在梳理材料的时候,就决定从源头入手——即“为什么”。
架构演进之“微服务架构

  

架构是演进的,不是一蹴而就。

  

架构演进之“微服务架构

  

"架构演进趋势图”中的趋势分析,在业界比较公认。这个图本身的内容,关于各个架构的描述,优缺点等等,网上简单搜索一下有大把大把的,感兴趣的同学可以自行搜索,毕竟这也不是我们文章的重点。

  

软件发展的不同时期,阶段,对技术的理解,选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。

  

什么是“微服务架构”?

  

架构演进之“微服务架构”“> <br/>既然聊的是“为什么”,那么首先要明白”什么是”。</p>
  <p>   

架构演进之“微服务架构

  

提到微服务,就没法不提到这位“大神”——马丁·福勒,他没有直接给微服务下一个精准的定义,而是给出了微服务特点的描述,大概从以下四个方面来说:

  

1。根据业务模块划分服务种类
2。每个服务可以独立部署并且互相隔离
3。通过轻量的API调用服务
4。服务需要保证良好的高可用性

  

架构演进之“微服务架构”“> <br/>怎么理解呢?以下是我的解读:</p>
  <p>第一点,按业务拆分服务,这是“水平拆分”;在技术层面的“前后分离”,属于“垂直拆分”,横纵一起切,就把单一的应用拆分成网状的小块应用,这是微服务中“微”思想的体现。</p>
  <p>第二点,独立部署与互相隔离,这点充分体现了“我为人人,人人为我”的设计理念,这是微服务中“服务”思想的体现。</p>
  <p>第三点,关于轻量API,微服务本身是推荐使用轻量的通讯协议和简单的数据结构,实际上,实施环节通常采用的都是http + json的方式。这样做的好处是,服务之间不再需要关心对方的模型,仅通过事先约定好的接口来进行数据流转即可。这是微服务中“解耦”思想的体现。</p>
  <p>最后一点,比较通用了,就是现如今各种设计都必须考虑的事情。</p>
  <p>于是,我给微服务下了一个定义(如图)。<br/> <img src=

  

在实际工作中,我们遇到过各式各样的问题,有些是技术问题,有些是业务问题,还有些是管理问题,这里拿其中一个案例来说一下。

  

架构演进之“微服务架构”“> <br/>这种事情说大不大,说小不小。其中最麻烦的事情是“推”诿的发生,每个独立组织都有自己的考核指标和关注点,而实际情况又不可能把具体的一个任务的界限划分得特别清晰。例如接口定义,哪怕说的是“双方坐下来一起商讨决定”,最终还是会有一方对此事负责,推诿在所难免。</p>
  <p>微服务的指导思想其中一块就是关于组织机构调整的,这还有个专门的定律叫“康威定律”,感兴趣的可以自行搜索了解。</p>
  <p>我们的解决办法也很有效果。在组织机构没有完全按照微服务的理念重新规划之前,这类需要跨组织协同完成的任务,直接成立临时项目组:相关的部门出人的出人、出资源的出资源,指定/选拔一个能保持住的项目经理对整件事情负责,然后大家惊奇的发现:“部门墙”问题不见了,因为所有事情都是组内事情了,整体的完成情况跟全部项目组成员的业绩都挂钩了,事情推进就非常顺利。在顺利交付之后,项目组解散,各回各的家。极大的提升了沟通效率,交付速度,同时使得资源利用率也得到了很大的提升。<h2 class=架构演进之“微服务架构”