前言

补上周的阅读任务，Martinfowler的《微服务》，英文版读了一遍，读起来是真的慢，然后对照csdn上的中文翻译版又读了一遍。作为小白，项目经历不足导致一些术语和场景理解起来不是特别清晰，就简单地整理摘抄了一部分内容作为阅读笔记了。

原博文地址
http://martinfowler.com/articles/microservices.html
译文地址
https://blog.csdn.net/wurenhai/article/details/37659335

概述

微服务架构是最近几年里出现的用于描述一种独立部署的软件应用设计方式。这种架构方式虽然没有明确定义，但是应用广泛。相比于条目清晰明确的协议，微服务更像是一种风格。
微服务风格就是将小的服务开发成单一应用的形式，每个应用运行在单一进程中。这些服务可以使用不同的编程语言和存储技术。

与整体风格的对比

与微服务相对应的风格是整体风格，也就是把一个完整应用当做开发单元。这种单元通常包括客户端界面，数据库和服务端应用三个部分。也就是对应前端、数据库和后台三个部分。其中服务端的应用是一个整体，想要对系统进行任何变更都需要重新发布一个新版本。
因此这就导致了整体风格的缺点，本来我们可能只需要更新系统的一个小部分、小模块，大部分都不需要重新编译，但是这样就需要全部都重新编译和部署。因此微服务的优点就显现出来了，服务可以独立部署、独立扩展，服务也可以提供模块化的边界，这样服务就可以按需更新了。

组件与服务

首先是微服务风格对组件、组件库以及服务的定义
- 组件：软件中独立的单元，它能独立替代和独立更新
- 组件库：程序中相互关系、并使用内存中调用的组件
- 服务：进程间使用如Web请求服务或者远程调用来相互通信的组件

将服务定义组件的一个原因是服务可以独立部署，每个服务的变更只需要发布相应的服务。另一个原因是这样可以拥有更加清晰的接口。
不过使用服务也有其缺点。远程调用的消耗比进程内调用更高，因此API设计需要更加粗粒度，也更加难用。

围绕业务功能进行组织

之前我们对团队的划分通常是通过技术来划分的，例如我们将技术团队分为UI团队，数据库团队和后台团队，这种划分会导致项目中任何一点改变都会产生巨大的交流沟通成本。如下图所示

产品不是项目

大部分的软件开发模式都是由开发组进行软件开发，开发完成之后转交到维护部门，之后开发组就此解散，不再对软件负责。
而微服务的理念则与此相反，认为开发组应该负责其软件的整个生命周期，也就是负责开发、运维甚至产品的售后工作。这样可以使得软件开发团队与用户的联系更加紧密。

强化终端及弱化通道

之前很多的进程通信的时候，很多产品都会将重点放在通信机制上。而微服务则更加强调将重点放在终端而不是通信机制上。微服务追求低耦合和高内聚，更喜欢简洁的REST风格，其逻辑如下
接受请求 -> 处理业务逻辑 -> 返回响应
一方面，微服务选择了基于互联网构建系统的理念，这样用户可以轻易的获取需要的服务和资源，另一方面采用轻量级的消息总线来发布消息，因为通信机制简陋单一，因此需要终端来加强对消息的处理。

去中心化的管理

集中管理的优点在于在一个平台上可以实现标准化。而微服务则更加喜欢用不同的工具来处理不同的问题，这样更加具有针对性。例如你可以用node.js开发报表，用cpp构建高性能要求的组件，以及用不同的数据库存储不同需求的数据。

去中心化的数据管理

企业通常选择单一的某个数据库来存储应用中的全部数据。
微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。

自动部署

微服务支持高效的自动部署。
自动化技术的发展，减少了构建、发布、运维微服务的复杂性。
持续部署的一个目标就是让部署工作变得简单而无聊。

容错性设计

在出现服务故障的情况下，客户端需要优化这种场景的响应页面。
由于服务可以随时故障，快速故障检测和自动恢复就显得非常重要，各个阶段都应该具备监控措施，对于异常数据监控设备可以给运维团队提前预警。

设计改进

服务应该是能够报废的，而不是一定要长久发展的。报废服务也是一种控制变化的方式。