微服务作为最近比较火的技术架构，大家的理解会存在较大的偏差，我在这里尝试梳理一下自己对微服务的认识与理解。主要内容来源于杨波在极客时间中的微服务课程，感兴趣的老铁可以去看一下
定义
理论源于马丁·福勒关于微服务的定义
- 将单体应用划分为一组小服务，服务之间相互协作，实现业务功能
- 每个服务运行在独立的进程中，服务间采用轻量级通信机制协作（HTTP/JSON）
- 每个服务围绕拆分后的业务能力进行构建，并且能够通过自动化机制独立部署
- 很少有集中式的服务管理，每个服务可以使用不同的语言和不同的存储技术
- 是一种基于有界上下文，松耦合的面向服务的架构
pros & cons
pros
- 强模块化边界
在面向对象编程中有类和组件类库的概念，以此来实现模块化复用。微服务再提升一层，在服务层面做模块化复用 - 可独立部署
一个小团队可以独立去开发，部署一个微服务组件 - 技术多样性
cons
- 分布式系统复杂性
服务数量多了之后，系统的调用关系会变得非常复杂 - 最终一致性
在数据层面，每个服务会有自己的数据库，不同服务数据库之间的可能会引发数据不一致的情况 - 运维复杂性
对运维来说，需要管理分布式系统是比单块系统难很多的。需要引入自动化运维技术，尽可能把运维工作交由机器处理 - 测试复杂性
一个服务的变更需要很多服务团队一起做联合测试
其实软件的架构也好，公司组织架构也好，本质上还是以分工促效率，微服务的强模块边界和独立部署降低了协同开发成本，但是相应的测试和运维成本上来了，还是应了那句老话，没有银弹。
另外根据康威法则：
Organizations which design systems … are constrained to produce
designs which are copies of the communication structures of these
organizations.
IT部门人事组织架构应当与软件架构等价或者说匹配。那么微服务的组织架构是什么样的？首先来看下老黄历
旧组织结构
接下来是NetFlix的微服务组织架构
微服务组织结构
每个团队负责一个到多个微服务，利于长期沉淀
引入微服务的时机和坑点
如图所示，只有系统复杂性达到瓶颈才适合开始考虑引入微服务，否则还是单块应用的效率高些。有的专家提出开发人数到达50-100人左右可以开始考虑。
从单块应用到微服务必然涉及到业务的拆分，拆分后服务互相调用以及版本控制都是很麻烦的。Google和FB这样的大公司里面，整个系统做得相当成熟，测试环境做得非常完美。每个服务都对应设置了在线的测试服务，写集成测试极其方便，或者把服务做成开箱即用，工程师可以一次性地建立所有的本地服务进行联调和测试，但是，对于大部分创业公司来说，很难达到这个水准。另外一旦系统报错，追踪到服务边界的接口处就要看其它服务的程序猿是否把异常信息封装后层层传播出去，并最终暴露到接口的4xx响应里面，但是不能保证大家都这样做了。另外还涉及到了请求超时，代码自由性等问题。
因此还是需要遵循单块系统优先的原则
直接走微服务难点在对业务理解程度不够，很难划分微服务的边界。另外还有一点就是业务未成熟，微服务在系统复杂度不高的情况下，改动起来没有单块应用来的方便。毕竟架构是适度设计+长时间衍化产生的
阿里的中台架构
阿里的中台架构如图
PaaS层和微服务架构是类似的，而ERP/OA/HR/CRM等系统可以理解为技术后台，其实中台架构有点像对微服务进行了类型上的划分，做了服务分层。当然还存在其它的服务分层方式，如图：
在这张图里面，底层服务都是原子性服务，BFF是聚合裁剪服务，给前端做适配。
推荐阅读
1《微服务设计》，偏原理
2《Spring Microservices in Action》，暂无中文版，原理＋Spring Cloud实战
网友评论