本文翻译并总结Martin Fowler的个人网站中有关微服务的资源指南。Martin是书籍《重构:改善既有代码的设计》的作者，很早就开始关注微服务的架构设计。这篇指南主要由Martin个人所甄选的有关微服务架构设计的文章，视频，书籍和博客组成。也希望通过这篇指南给关注微服务架构的人一个上手的起点。

指南主要分为4个部分：

  1. 什么是微服务？
  2. 什么时候需要用微服务？
  3. 如何构建微服务？
  4. 哪些公司或机构在用微服务？

什么是微服务？

简单来说，微服务架构设计指的是通过一套细分的多个服务来开发一个完整应用的方式，其中每一个服务都在各自独立运行，并通过轻量的对接方式来交流，通常是包含HTTP资源的API请求。这些单个服务根据自身业务需求来创建，并且有自动部署系统来独立部署。所有的服务很少需要集中管理，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
– James Lewis and Martin Fowler

微服务架构定义

首先最值得精读的文章要数James Lewis和Martin Fowler联合撰写的
Microservices: a definition of this new architectural term，中文版戳这里。

微服务架构讲座

Martin在不同会议上有关微服务的讲座，包括微服务的定义，和单片架构(Monolithic architecture)的对比，以及部署微服务应用之前所需要做的事。

微服务与分布式对象

分布式对象(Distributed Object)指的是分布在同一电脑中不同进程，或者通过网络连接的不同电脑中的对象。主要为了解决在不同进程中共享数据或者方法调用的问题。这篇文章讲了微服务与分布式对象之间的关系。

微服务与Service-Oriented Architecture

Matt McLarty的这篇文章详细讲述了SOA的发展历史，以及它与微服务架构之间的关系。

什么时候需要用微服务？

首先，需要了解微服务架构的优缺点的权衡，具体参照Microservice Trade-Offs一文。这里简单总结了微服务架构的优缺点。

优点：

  1. 强模块化(Strong Module Boundaries)
    微服务加强了设计上的模块化结构，对于比较大型的团队尤其重要。
  2. 独立部署(Independent Deployment)
    单个的小型服务比较容易部署，并且由于每个服务有具有独立自主性，出现问题也较少导致整个系统崩溃。
  3. 技术上的多样性(Technology Diversity)
    微服务架构允许在不同的服务之间灵活地选择不同语言，开发框架，以及数据存储技术。

缺点：

  1. 分布式(Distribution)
    分布式系统比较难以开发，远程调用出现问题的风险比较高。
  2. 系统最终的一致性(Eventual Consistency)
    维护并保持一个分布式系统的强一致性十分困难，要求每个开发人员都必须考虑到系统最终的一致性问题。
  3. 系统运行的复杂性(Operational Complexity)
    可能需要一个专门的运维组来管理多个服务，并且这些服务可能会不时地进行更新和重新部署。

如何构建微服务？

强烈推荐本书《Building Microservices》。作者Sam Newman详细介绍了微服务的起源，以及涵盖了微服务架构设计如何应用在整个软件开发周期的方方面面。

测试

参考Toby Clemson撰写的关于微服务架构下需要考虑的不同种类的测试Testing Strategies in a
Microservice Architecture。

单个服务大小

微服务架构中一个重要话题就是如何定义单个服务的大小。可以参考一下资料：

安全性

讲座

上线前的先决条件

Martin在Microservice Prerequisites一文中列出了微服务架构设计的应用上线前所需要准备的条件，提炼如下：

  • 快速配置(Rapid Provisioning)
  • 基本监测(Basic Monitoring)
  • 快速部署(Rapid Application Deployment)
  • DevOps文化(DevOps Culture)

哪些公司或机构在用微服务？

更多资料