http://kaelzhang81.github.io/2017/09/14/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E4%B9%9D%E5%A4%A7%E7%89%B9%E6%80%A7/ 作者：Kaelzhang on September 14, 2017
微服务的九大特性是微服务架构风格的重要设计原则。在Martin Fowler的官方博客上有详细阐述。不过由于该文篇幅比较大，阐述略为细致，对于读者来说不好把握其重点，故通过本文对其进行提炼总结。
特性一：“组件化”与“多服务”
解释 通过服务的方式实现系统的组件化。
原因
- 服务可独立部署、发布
- 服务接口更加明显（explicit）
说明 组件：被链接到程序，通过内存中的函数来调用。 服务：进程外的组件，通过诸如web service请求或RPC的机制通信。
特性二：围绕“业务功能”组织团队
解释 通过业务的划分来组件团队。
原因
- 端到端的业务服务（全栈、自治）
- 有效降低变更成本
- 团队边界更清晰
说明 传统组织是按照技术层面划分的，例如： UI团队、后台团队和数据库团队。该划分方式的弊端是当业务变更发生时，需要跨团队才得以完成，成本比较高。
特性三：“做产品”而不是“做项目”
解释 以做产品的方式来开发服务，对其整个生命周期（包括：测试、部署及运维）负责。
原因
- 做项目相当于奶妈，做产品类比于亲妈
- 微服务更便于掌握和维护
说明 对单体架构产品也适用，不过其由于关注面更大，导致难度更大。另外想强调的内容是“谁构建，谁运行”这一DevOps理念。
特性四：“智能端点”与“傻瓜管道”
解释 服务自身需要能够自治，服务之间的交互要轻量化。
原因
- 像经典Unix的“过滤器”(filter)那样来工作
- 轻量级的通信方式更易整合
- 与ESB的中心化和哑服务形成对比
说明 轻量级通信机制：
- 使用HTTP协议的RESTful API或轻量级的消息发送协议，来实现信息传递与服务调用的触发。
- 通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的结构。
-
特性五：“去中心化”地治理技术
解释 技术实现方案无需“中心化”指定，而根据服务自身情况来选择。
原因 采用轻量级的契约定义接口
- 服务之间的交互对技术选型不敏感
说明 不是每一个问题都是钉子，不是每一个方案都是锤子。
特性六：“去中心化”地管理数据
解释 服务的数据持久化也是自管理的，无需统一安排。
原因
- 服务之间的数据交互仅能通过服务接口来完成。
- 无需数据库层面的数据共享
说明 方式：
- 数据库中的存储内容拆分到新的同平台的其他数据库实例中
- 对具有特殊结构或业务特性的数据存储到其他技术的数据库实例
问题： 数据一致性也成为“微服务”架构中急需解决的问题之一，强调最终一致性。
特性七：“基础设施”自动化
解释 必须一开始就构建起“持续交付”平台来支撑整个实施过程。
原因
- 由原来的单系统编程多系统
- 云计算、容器技术以及DevOps的发展
说明 自动化测试：每次部署前的强心剂，尽可能的获得对正在运行软件的信心。 自动化部署：解放繁琐枯燥的重复操作以及对多环境的配置管理。
特性八：“容错”设计
解释 微服务整体复杂性比单体架构要高，故其需要更强调“容错”设计。
原因
- 服务数量多，依赖关系复杂
- 故障定位困难
- 微服务存在“雪崩效应”
说明 “雪崩效应”： 如果在A服务的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住，堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃。
方式：
- 故障检测
- 自动恢复
特性九：“演进式”设计
解释 控制变化并不一定意味着要减少变化，当变化发生时架构要进行演进
原因
- 服务可独立更换和升级
- 需求变化是必然发生的
说明 必须要考虑当一个服务发生变化时，依赖它并对其进行消费的其他服务将无法工作
参考资料：
若有收获，就点个赞吧
0 人点赞
