微服务是什么?

简单来说,微服务架构风格想要开发一种由多个小服务组成的应用,每个服务运行于独立的进程,并且采用轻量级交互,多数情况下一个HTTP的资源API,这些服务具备独立业务能力并可以通过自动化部署方式独立部署,这种风格使最小化集中管理,从而可以使用多种不同的编程语言喝数据存储技术 -----James Lewis 和 Martin Fowler

img

高内聚低耦合

  • 紧密关联的事物应该放在一起,每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情(每次只有一个更改它的理由)。如下图:有四个服务a,b,c,d,但是每个服务职责不单一,a可能在做b的事情,b又在做c的事情,c又同时在做a的事情,通过重新调整,将相关的事物放在一起后,可以减少不必要的服务。

  • 轻量级的通信方式

  • 同步RESTful(GET/PUT/POST...),基于http,能让服务间的通信变得标准化并且无状态,关于RESTful API的成熟度,可参Richardson为REST定义的成熟度模型

  • 异步(消息队列/发布订阅)

  • 避免在服务与服务之间共享数据库

高度自治

独立部署运行和扩展

  • 每个服务能够独立被部署并运行在一个进程内
  • 这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏,使得快速交付和应对变化成为可能。

独立开发和演进

  • 技术选型灵活,不受遗留系统技术栈的约束。
  • 合适的业务问题可以选择合适的技术栈,可以独立的演进
  • 服务与服务之间采取与语言无关的API进行集成

独立的团队和自治

  • 团队对服务的整个生命周期负责,工作在独立的上下文中, 谁开发,谁维护。

以业务为中心

  • 每个服务代表了特定的业务逻辑
  • 有明显的边界上下文
  • 围绕业务组织团队
  • 能快速的响应业务的变化
  • 隔离实现细节,让业务领域可以被重用

弹性设计

  • 设计可容错的系统
    • 拥抱失败,为已知的错误而设计
    • 依赖的服务挂掉
    • 网络连接问题
  • 设计具有自我保护能力的系统
    • 服务隔离
    • 服务降级
    • 限制使用资源
    • 防止级联错误

日志与监控

当产品环境出错时,需要快速的定位问题,检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择,在微服务架构中更是至关重要。

  • 高度可观察,我们需要对正在发生的事情有一个整体的视角。
  • 聚合你的日志,聚合你的数据,从而当你遇到问题时,可以深入分析原因。
  • 当需要重现令人讨厌的问题,或仅仅查看你的系统在生产环境如何交互时,关联标识可以帮助你跟踪系统间的调用。

自动化

在微服务架构下,面临如下挑战:

  •  分布式系统
  •  多服务,多实例
  •  手动测试,部署,发布太消耗时间
  •  反馈周期太长

传统的手工运维方式必然要被淘汰,微服务的实施是有一定的先决条件:那就是自动化,当服务规模化后需要更多自动化标准化的手段来提升效能和降低成本。

  • 自动化测试必不可少,因为对比单块系统,确保我们大量的服务正常工作是一个更复杂的过程。
  • 调用一个统一的命令行,以相同的方式把系统部署到各个环境。
  • 考虑使用环境定义来帮助你明确不同环境间的差异,但同时保持使用统一的方式进行部署的能力。
  • 考虑创建自定义镜像来加快部署,并且拥抱全自动化创建不可变服务器的实践。

自动化一切可以自动化的,降低部署和发布的难度, 比如: 在持续集成和持续交付中,自动化编译,测试,安全扫描,打包,集成测试,部署,随着服务越来越多,在发布过程中,需要进一步自动化蓝绿部署(做到老版本到新版本的平滑过渡)还可以使用pipeline as code的实践,用代码来描述你的流水线。