Mircoservices

Mircoservices

该新架构术语的定义
术语 “Mircoservices Architecture” 在近几年兴起，描述一种特定的设计软件应用的方法–独立部署的服务程序组。然而没有对这种架构风格的精确定义，在组织，事务能力，自动部署，终端智能，和语言和数据的分散控制方面，有一些常见的特性。

简单来说，微服务架构风格是将单个应用作为一组小服务程序组的开发方式，每个都运行在自己的进程中，以更轻量的方式通讯，通常是 HTTP resource API。这些服务围绕业务功能构建，并且能够通过完全自动化的部署机制自动部署。对这些服务进行最低限度的集中管理，它们可能使用不同的编程语言编码，并使用不同的数据存储技术。

微服务架构以服务程序组构建应用，服务能够独立部署和拓展，每个服务也提供稳固的模块边界，甚至允许使用不同的编程语言来写不同的程序。它们也能被不同的团队管理。

Characteristics of a Microservice Architecture

当我们讨论组件（component）时，我们很难定义出什么是组件。我们的定义是组件是能够被独立替换和更新的软件单元。

微服务架构将使用库，但是它们组件化软件的主要方法是将软件分解为多个服务。我们定义库为组件，将它们链接到程序中，并称之为使用内存中函数调用，然而服务是进程外的组件，它与例如 web 服务请求或者远程服务调用这样的机制进行通讯，

使用服务（而不是库）作为组件的一个主要理由是服务能够独立部署。如果你有一个应用是由多个库组成一个单独的进程的话，任何单独组件的修改都会导致整个进程的重新部署。但是如果这个应用解组为多个服务，你可以期望许多单个服务的改变仅需要重新部署该服务。但这不是绝对的，一些改变将改变服务接口，会导致一些服务间协调，但是一个好的微服务架构的目标就是通过固化的服务边界和服务契约的演化机制来最小化这些问题。

使用服务作为组件的另一个结果是更显式的组件接口。大部分语言没有一个好的机制来定义一个显式的 Published Interface。通常只有文档和规则来避免客户端破坏组件的封装，导致组件间过度紧密耦合。服务通过使用显式的远程调用机制，能更简单的避免上述问题。

这样使用服务确有缺点。远程调用较进程间调用成本更高，因此远程的 API 需要更粗的粒度，这通常更不便于使用。如果你需要改变组件间的职责分配，当你跨越进程边界时，一些行为的移动变得更加困难。

在一开始的近似下，我们能注意到服务映射到运行时进程，但这只是第一次近似。一个服务可能由多个进程组成，它们将总是一起被开发和部署，例如一个应用进程和仅被该服务使用的数据库。

Organized around Business Capabilities

在考虑将大的应用分割成多个部分，通常管理会集中于技术层，导致分为 UI teams，服务端逻辑 teams，和数据库 teams。当团队按照这些 lines 来分的话，即使简单的改变也会导致跨团队工程花费时间和预算批准。
…

Smart endpoints and dumb pipes

微服务团队使用在其上建立 world wide web（很大程度上，Unix）的原理和协议。开发人员和运维人员能够耗费很少的努力就能缓存经常使用的资源。

第二个常用的方法是在轻量级的消息总线上传递消息。基础设施的选择典型地为 dump（dump 仅作为消息路由（router））- 简单的实现比如 RabbitMQ 或 ZeroMQ，仅简单的提供一个可靠的异步交换机构 - 智能依然存活在生产和消费消息的终端，在服务端。

作为一个整体，组件在进程中执行，它们之间的通讯通过方法调用或函数调用。将整体变为微服务最大的问题是改变了通信模式。从内存内方法调用到 RPC 的天然转变导致絮叨的通讯表现得不好。因此你需要将细粒度得通讯替换为粗粒度的通讯。

Decentralized Governance

集中治理的结果之一是在单一平台上的标准化趋势。经验表明这种方法是狭隘的 - 不是每个问题都是钉子，不是每个解决办法都是锤子。我们更愿意为工作使用正确的工具，虽然整体应用可以在一定程度上利用不同的语言，但这并不常见。

将整体应用切分为服务，这样我们在构建服务时就能做出一些选择。你想要 Node.js 来建立一个简单的报告页面？这样做吧。C++ 用于特别粗糙的 near-real-time 组件？可以。你想要切换不同的数据库风格，以便更好的适应某个组件的读行为。我们有技术来重构它。

当然，你能够做一些事，并不意味着你应该这样做 - 但是部分化你的系统为你提供了这个选项。

Decentralized Data Mangement

微服务更偏爱让服务管理它自己的数据库，要么是相同数据库技术的不同实例，要么是完全不同的数据库系统 - 一种称为 Polyglot Persistence。你可以在整体应用中使用混合持久化，但它在微服务中出现的更加频繁。

跨微服务数据的去中心责任对管理更新有影响。处理更新的常用方法是当更新多个资源时，使用事务来保证一致性。这一方法通常用于整体。

使用这样的事务有助于保持一致性，但会带来显著的时间耦合，在多个服务之间这是有问题的。分布式事务是十分难以实现的，所以微服务架构强调服务间无事务协调，显式的认识到一致性可能只是最终的一致性，问题可能被补偿操作解决。

Infrastructure Automation

基础设施部署技术在近几年有了极大的进步 - 云特别是 AWS 的进步减少了构建，部署和运行微服务的复杂度。

Design for failure

使用服务作为组件的一个结论是，应用需要被设计成能够容忍服务的失败。因为提供方的不可靠性，任何服务的调用都有可能失败，client 必须尽量优雅的处理这种情况。相较于整体设计这也是缺点之一，它必须引入额外的复杂度来处理这些问题。

因为服务可能在任何时候失败，快速检测失败，如果可能的话，自动恢复服务变得十分重要。微服务应用将很多的重心放在应用的实时监控上，检查架构元素（数据库每秒有多少请求）和业务相关度量（比如每秒收到多少订单）。语义检查能提供一个早期警告系统，警告某些事发生了错误。

监视能够构建一个微服务一样透明 - 事实上，它应该如此。不同之处是，你绝对需要知道运行在不同进程中的服务何时断开连接。

Evolutionary Design

微服务的实现者，通常由进化式设计背景，且将服务分解视为进一步的工具使应用开发者能够控制他们应用中的改变且不会放缓改变。改变控制并不意味着改变的减少 - 使用正确的态度和工具你可以对软件做出频繁，快速和良好控制的改变。

组件的关键属性是独立替换和更新的概念 - 这其中隐含着我们寻找一个点，我们能设想到在该点重写组件而不会影响其他协作者。