微服务

微服务

• 译文：http://blog.cuicc.com/blog/2015/07/22/microservices/
• 原文 ：https://martinfowler.com/articles/microservices.html

1、什么是微服务

• 一种软件架构

• 微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

  • 单一应用程序：例如Tomcat 作为服务器开发一个简单的jsp项目（简单的MVC）
    • 和用户交互的前端页面
    • 处理用户通过前端页面发起的请求（curd之类的或者其他的业务逻辑处理）
    • 对请求需要的数据操作做持久化处理
  • 特点
    • 高耦合当系统的某处出现了改动需要整体配合改动
    • 运行在同一台服务器上，当负载过大时很难做到针对性扩充（某一功能模块，不可能每个模块的消耗都是一样的），可以通过运行多个实例进行整体扩充
    • 很自然，我们可以使用oop语言的特性很好的去划分

2、微服务应用程序

• 组件插在一起构建系统

  • 组件：可独立替换独自升级的软件单元
    • 服务组件化：把服务按一定规则抽象为可插拔的组件 解决了单一应用程序耦合强不能针对单一模块升级
    • 软件进行组件化：主要方法是将软件分解为诸多服务（然后拔插这些服务？按什么来划分）
    • 软件库：能被链接到一段程序，且能通过内存中的函数来进行调用（不太懂）
    • 服务：在进程之外（单一应用程序都是运行在同一进程），通过web service请求（接口）或远程过程调用这样的机制来进行通信（区别于web 开发中的service）
      • 我们可以意识到如果远程通信获取服务，那么就会需要考虑分布式，异步，那么单台服务器的压力可能会得到减少
      • 每个服务可以被独立部署（如果它没有被引用，多服务协作），作为组件，当单个服务需要被修改或者升级就不需要考虑整体
      • 我们服务可以使用不同的设计语言不同的数据库技术去实现，（没人关注你的实现，功能能否提供才是重点）

• 服务的划分：很明显如果服务组件化，那么服务的划分非常重要，按什么标准去划分，怎样划分最好（一个好的微服务架构的目的是通过内聚服务边界和按合约演进机制来最小化这些协作）

  • 当你试图把软件系统组件化时，你就面临着如何划分成块的决策 - 我们决定分割我们的应用的原则是什么？组件的关键特性是独立的更换和升级的理念 这意味着我们要找到这样的点，我们可以想象重写组件而不影响其合作者。

3、围绕业务能力组织

• 微服务采用不同的分割方法，划分成围绕业务能力组织的服务。这些服务采取该业务领域软件的宽栈实现，包括用户接口、持久化存储和任何外部协作。因此，团队都是跨职能的，包括开发需要的全方位技能：用户体验、数据库、项目管理（右边）（按功能贯穿了？）。

• 按层分（想不出好词）：management focuses on the technology layer, leading to UI teams, server-side logic teams（左边）

  • 当团队沿着这些技术线分开后，即使要实现软件中一个简单的变更，也会发生跨团队的项目时延和预算审批

• 

• 按不同业务来划分团队，团队之间通过（消息）总线同行（只需要协调处理自己团队内部的问题）相对而言需要的技术栈就越多

• 大型单体应用程序也总是可以围绕业务能力来模块化，虽然这不是常见的情况。当然，我们将敦促创建单体应用程序的大型团队将团队本身按业务线拆分。我们看到这种情况的主要问题是他们趋向于围绕太多的上下文进行组织。如果单体横跨了多个模块边界，对团队个体成员来说，很难把它们装进他们的短期记忆里。另外，我们看到模块化的路线需要大量的规则来强制实施。

  • 单一应用程序也可以围绕业务能力来划分（虽然现在例子很少？）
  • 趋向于围绕太多的上下文进行组织（定义了很多全局性的东西？）
  • 单体横跨了多个模块边界、难把它们装进他们的短期记忆、需要大量的规则来强制实施
  • 全局变量的存在需要带来资源消耗？语言特性和语句执行时间顺序带来的语法问题（需要考虑和解决）？

4、做产品而不是做项目

• 微服务的细粒度使得它更容易在服务开发者和用户之间建立个人关系

• 联系产品思想与业务能力、持续关注软件如何帮助用户提升业务能力，而不是为了交付软件而开发（个人会得到能力提升？）

5、智能端点和哑管道

• 在单个服务内部做大量处理，它们拥有自己的领域逻辑（即接收一个请求，酌情对其应用业务逻辑，并产生一个响应）
• 通过使用一些简单的REST风格的协议来进行编制（哑管道，简单）

6、去中心化治理

• 看不懂

7、“去中心化”地管理数据

• 微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例
  • 每个服务使用自己的数据库（当数据重合？）
• 当应用程序被划分成分离的组件时。一个有用的思维方式是有界上下文([Bounded Context]内的领域驱动设计(Domain-Driven Design, DDD)理念。DDD把一个复杂域划分成多个有界的上下文，并且映射出它们之间的关系。这个过程对单体架构和微服务架构都是有用的，但在服务和上下文边界间有天然的相关性，边界有助于澄清和加强分离

8、基础设施自动化

9、为失效设计

• 当我们使用服务作为组件，那么我们就必须思考当服务处于无法提供状态时客户端如何妥善的处理
  • 需要有快速检测和自动修复服务故障的能力

10、进化式设计

• 当你试图把软件系统组件化时，你就面临着如何划分成块的决策 - 我们决定分割我们的应用的原则是什么？组件的关键特性是独立的更换和升级的理念这意味着我们要找到这样的点，我们可以想象重写组件而不影响其合作者。

  • 如何划分

• 不断地一起改变两个服务，这是它们应该被合并的一个标志（有共性）

• 应用程序开发者能够控制他们应用程序中的变更而不减缓变更。变更控制并不一定意味着变更的减少 - 用正确的态度和工具，你可以频繁、快速且控制良好的改变软件