微服务,一种软件架构新风格

​ 微服务（Microservices）做为近年来兴起的软件架构，Martinfowler在其多年前就在论文中提出，下面就跟大师一块儿来领略微服务究竟是什么？多多指教。

原文连接：https://martinfowler.com/arti...

---

​ 微服务是一种架构风格，相比于传统单体应用，微服务以服务套件的方式来提供服务，每一个服务有本身的进程，服务间以轻量级通讯机制，一般是http，没有中心管理机构。单体应用的组成方式则是client，service，database，系统改变须要整个单体应用从新部署，缺点在于随着版本的更新，很难保持模块化结构，在模块内修改,且扩展成集群模式时须要耗费大量没必要要资源。

微服务特色

1. 服务组件化：

   • 微服务经过将系统经过服务分割的方式使其组件化，即服务套件，每一个组件可独立替换和更新，应用改变只须要从新部署对应服务，固然也不绝对，由于要考虑该服务合做的一些服务。
   • 通讯方式：微服务的通讯是轻量级进程间通讯（process-out），一般是http，相比于单体应用进程内（inter-process）通讯，通讯消耗大，因此一个API最好是粗粒度的，减小请求次数；
   • 拥有更显示的组件接口：大部分语言没有一个好的机制来定义公开接口，一般只是文档和一些规则来限制打破组件封装，达到紧耦合目的，微服务经过显示RPC使这种操做变得简单。
   • 当须要修改时，若是跨越服务边界，则在修改时比单体应用更为困难。
   • 近似看，一个服务对应一个进程，可是一个服务能够包含多个进程。

2. 围绕业务能力组织团队

   • 1. broad-stack 团队组织：传统系统的形式是前端，后端，数据库的形式，一个小的改变都会须要整个团队来进行配合。微服务团队应该根据服务的分割构建团队，每一个小团队都有前，后，数据库，造成broad-stack形式的Team，服务组件分割的越透明，那么团队边界就越透明。

     

3. 产品而非项目

   • 产品心态作服务：大部分人将软件当作一项功能的集合，功能开发完则团队就解散掉。微服务提倡避免这种模式，一个团队应该对一个产品的生命周期负责，you build , you run it ! 不能讲交付当作一个功能的完成，应该以进行时的眼光发现如何帮助用户来提升业务能力，固然会带来一些维护压力。

4. 通讯方式：智能端点和哑管道

   • RESTish协议：微服务社区偏好两类通讯方式，HTTP协议和轻量级通讯总线，如RabiitMQ 和 ZeroMQ，哑是由于基础设施是哑的，只扮演消息路由角色，smart表如今endpoits生产与消费消息。
   • 通讯模式：从单体应用到微服务应用最大的转变就是通讯模式的改变，单体应用通讯是经过方法或函数调用，是进程内的，从进程内通讯转到进程间通讯会致使通讯复杂，因此应该用粗粒度的API替代细粒度的API。

5. 去中心化管理

   • 利用不一样语言优点：中心化管理的结果是在一个平台上进行规范，有限制的，并非一个锤子对应一个钉子。所以，将单体分割成组件服务，你能够用node实现页面报表，c++作近实时通讯服务，也能够用不一样风格的数据库来更好适应读行为。
   • 工具优点：微服务团队更倾向于用工具来解决广泛问题，而不是paper上的规范，如NetFlix公司开源的数据存储、进程内通讯等工具箱，通过良好测试。

6. 去中心化数据管理

   • 数据库再也不单一：每一个服务有本身的数据库系统。
   • 数据更新管理：单体应用中数据库用事务来保证一致性，微服务尽可能避免分布式事务，很难实现。

     

7. 基础设施自动化

   • 应尽量的创建自动化测试，部署流程，在这一方面与单体应用是一致的，让持续交付（CD)变得省时省力。如Netflix的开源工具包。

     

8. 失败设计

   • 服务监控：用微服务做为组件，须要考虑的一个重要问题就是容忍失败，每一个服务都有不可靠性，相比于单体应用的一个缺点，微服务在该方面更复杂，团队应该对每一个服务创建监控，如状态、操做、业务相关指标，更细节的如熔断器，当前吞吐量，延迟等。Netflix'x simian army就是这样一个工具。

9. 演变设计

   • 如何看待变动：微服务开发者应该讲服务的分解当作是进一步控制应用的工具，应控制改变而不是减小改变，能够更好的控制面对软件变化。
   • 分解一个组件的原则是什么？可独立部署和更新，咱们能够重写且不影响到它的合做组件。更进一步，开发者能够显示的报废它，而不是长期改进。
   • 模块化驱动变动思想：如上述的组件分割原则。一些经验，不多改变的服务应该与常常改变的服务不在一块儿；若是两个服务常常改变，那么两个服务应该被合并。卫报例子，从单体应用到微服务改造，核心仍然是单体应用，新功能用微服务构建，一些具备时效性事件，如运动，过时则废掉。
   • 发布：将服务做为组件思想增长了更多粒度性发布组件的机会，单体应用须要从新部署，微服务只须要单独部署该服务，简化加快发布流程，缺点是应该考虑服务对其消费者的影响。传统继承方法用版本号来解决这个问题，可是微服务来讲这是最后解决方案，应该在服务的总体设计上尽量的容忍改变。

10. 微服务是将来吗？

    • 微服务有众多优势，可是做者也不肯定会是将来软件架构方向，须要足够多的时间来证实。
    • 微服务还须要更成熟：好的系统是更好地适应组件，那么如何精确的肯定组件边界，演变设计能够更好地 肯定组件边界，让重构变得简单。可是当组件做为服务通讯时，重构则超过进程内通讯困难，特别是跨越服务边界的重构代码，接口须要其余组件配合，回退、测试能力你都应该具有。
    • 复杂性转移：若是组件不够清晰，那么本质就是在将组件的复杂度转移到组件链接处，因此你看着组件小简单，可是组件间链接变得复杂。世界历来都是守恒的。
    • 新技术用不用的跟团队有很大关系，好的团队用什么都好。
    • 建议微服务应用从单体应用开始，再逐渐使其模块化。但建议不是典范。