前言

从2014年开始，当我接触微服务之后，我发现在微服务的演进过程中，开发和测试、运维需要相亲相爱，紧密合作，才能取得理想的效果。

本系列文章主要包括三部分内容：

第一部分：微服务与 DevOps；

第二部分：微服务生态系统；

第三部分：微服务架构的工程实践；

我在2014年的时候接触到一个海外项目，当时客户希望用微服务架构、DevOps、持续架构来做数字化转型。

经过一年多的时间，我们将客户的核心业务拆分成几十个服务，并对持续交付、团队组成做了很多的改进，带来的效果是显著的，从原有的四个月的交付周期，提升到随时按需发布。

在2015年底的时候，我出版了国内第一本关于微服务架构相关的中文书籍，叫《微服务架构与实践》，同时我也是《DevOps Handbook》的中文译者之一。

一 、什么是“微服务”

微服务这个词从2013年开始在社区兴起，这是去年的国外一个比较活跃的开发者社区，对2000多家企业包括北美的、欧洲、亚太的做的调研报告。

在这份报告里提到，已经接近30%的企业在使用微服务架构，而15%的企业目前正在试验开发和测试微服务架构。剩下的24%的企业正在积极学习和拥抱微服务架构。

从这个数据来看，随着应用系统变得越来越复杂，我们的交付周期变得越来越短，市场的不确定性越来越高，微服务架构正在成为帮助我们提升应用架构层面的核心竞争力。

这篇文章是 Martin Fowler 在2014年在他的博客上定义的什么是微服务架构。

我们过去的软件都是单体应用，就是指虽然在架构设计上将应用分层。比如典型的三层架构。

对于这类应用，虽然从逻辑层面上划分成多层，但是在运行层次上只有一个进程在运行程序，这就是单体应用。

而微服务架构是将单体应用拆分成多个小的服务，每个服务能够独立开发、更新和部署，同时服务之间能够通过轻量级的协议去做协作。

轻量级协议是指跟语言无关、平台无关的协议，今天我们在业界里面用得最多的 RESTful 协议就是。每一个服务都能够被独立部署到类生产环境、生产环境或者其他我们定义的环境。

在这个定义出来之后，在社区引发了很大争论，什么叫“小的服务”？我们怎么理解“小的服务”？

记得在2015年推特专门有一场争论是关于如何定义小服务，当时提出的建议是通过代码行来定义小的服务。

但是在今天所面临的社区是一个非常多元化的社区，我们有各种语言，面向对象的、面向过程的，面向函数式编程的，每一种是不一样的，所以很难决定我们的服务是不是够小。

第二点，很多人提出如果我的服务在很短时间内被重写，是不是认为应该算一个比较小的合适的服务呢？对于重写这个事情也有比较大的场景化。比如说我们的工程师对业务的理解、工具的熟悉程度，都会影响到我们来如何定义这个“小”。对于“小”的定义，我们很难清晰的描述一个标准来决定什么是“小”，但是在演进过程中，尤其是服务化过程中，在一开始我不建议划分成很细的服务，因为它会为我们带来很多后续的瓶颈。

最后是独立的部署，这也是在社区被很多人误解。对于软件开发而言，很多年以前一直在讨论模块化编程，因为我们有DAL等等，都是帮我们模块化软件的方式。但到了今天，随着业务变得越来越复杂，我们希望能够将需求实现尽快发布出去，让用户使用，所以就演变成能够把这些模块化再抽象一步，做成独立部署的单元。所以这是微服务架构跟过去很多软件开发里最大、最本质的区别之一。

除了 Martin 以外，还有很多大师做了很多解释。

首先，Fred George 也是很早定义微服务的人。他曾经就职于IBM，还为金融、保险提供过咨询服务，在2013年的印度敏捷大会上，他第一次讲到，他们将一百多万行的银行程序，使用了非传统 SOA 的方式构建，通过持续集成，将这个服务拆分成20个，50个，200个，最后实现交付周期从一年变成一周或者几天，这是最早对微服务的介绍。

第二个是 Adrian，他所在的公司是Netflix，做在线视频服务。在北美三分之一的网络视频流量是来自于这家公司，同时这家公司还制作了一部非常经典的美剧叫《纸牌屋》。在他过去的演进中提到从09年到16年，将原有的核心系统拆分成了600多个服务，同时做了很多的创新，尤其是在开源社区做了很多创新。他的架构师对他们过程的定义，所谓微服务是指：loosely coupled service oriented architecture with  bounded  contexts。

最后一位是 Neal，他认为微服务架构其实是 DevOps 演进之后的一种新的架构模式。

对于现在很多社区的概念，我们没有办法去给出一个标准化的定义，所以经常会说「一千个读者心中可能会有一千个哈姆雷特」。这是过去我基于自己的理解，对微服务的关键所做的新的阐述——所谓“微服务”是指以缩短交付周期为核心，基于 DevOps 所构建的演进式架构。

我们为什么要以持续缩短交付为核心？

这是在美国举办的架构师大会上的一段话，这是业界最先进的架构领域的大会，我们交付特性的速度已经落后于业务变化的速度，这成为阻碍发展和丧失核心竞争力的因素。

随着我们今天软件的世界变得越来越快，很多企业在面临如何去对用户做创新的过程中，交付的频率变得越来越高，我们如何提升我们的效率。

提到持续交付、缩短交付周期。从2010年《持续交付》这本书诞生以来，它已经开始改变我们对软件交付的理解。如果大家再去翻这本书的时候会发现，那时候这本书的作者已经提到，我们未来所交付软件的方式是希望能够：

第一，缩短我们的交付周期；

第二，能够降低我们在交付过程中的成本；

第三，能够将我们的质量内置在交付过程中的每一个环节。

如果我们打开软件交付的过程来看，其实发现过去很多方法论的提出，都与缩短交付周期有着密切的联系。从需求阶段最经常提的概念叫 MVP，所谓「MVP」是指我们定义需求的时候，先来分析最小、最有价值的需求，将这部分需求尽快上线，来满足用户的期望或者做试验，获取反馈之后再来进行改进，所以是从整体上缩短交付周期的。

之前我们谈到敏捷是讲快速建立反馈闭环，通过我们的 PDD，能够让开发人员或者测试人员更好理解，在这个需求的阐述过程中，如何能够有效实现它的特性。

当我们实现了敏捷，当我们实现了持续集成，开发人员已经完成了这个包的构建之后，下一步所面临的，我们如何将它部署到生产环境上，这就是我们解决的最后一公里的问题，它包括我们今天所讲的 DevOps，包括持续部署。

二、DevOps 是什么？

「DevOps」这个词最早诞生的出发点是希望能够解决软件在交付过程中最后一公里的问题。当我们已经构建了这个发布包之后，如何能够高效尽快将它上线，再往后是监控运营，有很多监控运营方式帮助我们收集用户的体验，核心目的是为了能够更快验证我们的想法，提升我们的交付效率。

但是在持续交付里有一个重要的能力模型，它里面包括持续集成、持续部署、环境管理、数据管理以及松耦合架构。

在过去的四五年期间，我发现在社区上除了松耦合架构以外，对于其他很多模块都有非常多的解决方案。比如说对于持续集成，在2011年的时候，我们开始帮客户做持续集成的方案，对于持续部署也有一些方案能够解决，同样对于环境管理，我们今天所讨论的发布，大部分都会有开发、测试、类生产和生产环境。

你会发现在过去的很长一段时间里，社区一直在讨论我们如何去更好构建持续交付的能力，但是如果我们回过头来想，我们在之前的这几个模块里已经做了足够多的优化，但是当我们的架构如果无法解耦，还是百万行千万行，我们怎么快得起来。

最早我在接触两百万行代码的项目里，一开始我们没有办法对架构立刻解耦，所以我们曾经花了将近五台服务器去构建一个持续集成，从以前的2个小时变成后来的20分钟，这是我们解决提升交付周期的方式。我认为微服务架构其实是从松耦合架构的角度考虑如何以持续交付，缩短交付周期为核心的解决方案。

为什么基于 DevOps？

开发人员的天性是希望能够用一些先进的语言，更高效的工具去实现我们的业务特性。但是对于运维人员，我们是保证生产环境能够准确无误的运行，所以这个协作过程中必然出现冲突。

我过去接触过一些项目，当开发人员完成代码的提交验证之后，这个包就放在代码仓库里，这时候开发人员需要做的很多事情是，我需要去定义一个清晰的部署步骤，交给运维同事用，再把这个步骤和当前运营的版本交给主管，主管会和运维主管协同协作，确定好之后再排期给真正部署运维的人员。

因为在一个企业里，运维团队都是稀缺资源，可能会负责公司很多产品的运维，所以这个过程中有大量的流程化手动的工作去完成部署，回到微服务架构我们想想，当我们把架构拆成多个可以被独立部署的单元的话，这个流程受到的冲击就非常大，所面临的挑战是很大的，所以对微服务与 DevOps 是相辅相成的。

在 DevOps 体系里，相信这两天大家听了很多关于 DevOps 的介绍，我再总结一下，对于 DevOps，我认为它的最大几个核心点，就是右边的这四个英文单词——CAMS。

自动化工具是我们重要的一环，有了工具可以使开发人员通过自服务方式完成部署。但是这过程中更重要的是，我们需要团队在开发运维之间更好的协作，让他们互相了解对方所做的事情。

比如说运维人员有丰富的运维经验，能够将这些经验传递给开发，开发人员可以根据他所理解的这些知识把这些脚本化或者工具自动化。同时对于部署过程而言，开发靠近分析，他更清楚我对这次部署的风险，能够跟部署人员做紧密协作，让部署提前考虑我部署过程中的风险。

同时通过一些监控度量和共享方式，促成 DevOps 的理念和实践的落地，这在整个微服务演进过程中是非常重要的。

什么是演进式架构？

在过去很多年里我们的概念一直认为，架构一旦被确定很难被改变，这是瀑布模型阶段性的影响。因为在瀑布模型里我们有很清晰的架构设计阶段、编码阶段和测试阶段，当我们的架构发生一点变化之后，对后面所带来的成本和反馈周期是非常大的，所以我们在前期对架构要做非常完美的设计，我们定义了一个方框，但是当开发团队在实现的时候，会做各种各样的妥协，因为我们所面临的很多需求在未来是不确定的。

对于过去，当我们只有一种技术栈，我们只需要定义企业的通用平台去满足各种各样的需求，但是对于市场变化莫测的时代，很难再去框这个框，这样对前期成本非常高，也不利于过程中的改进。

所以在社区里对于架构新的理念叫「演进式架构」，它所定义的是希望将敏捷的方式应用在架构层面，将增量式变更作为架构里面必要的一环。提到这个问题大家会想，对于架构而言，我怎么做增量式变更呢？

第一，我们一定要认为架构是对一个软件团队和成本的动态平衡，我们只有在演进过程中，和技术团队、成本、需求紧密结合，不断调整动态平衡。

第二，运维意识很关键。在过去演进过程中，通常是使用UML去画好架构图，但是在现代的架构快速演进的时代，当我们的服务超过一百个，两百个，三百个之后，是很难诠释微服务架构的。对于架构而言，更多的是对软件静态的抽象，是对当前软件运行的快照，所以对于架构师和我的团队而言，只有当我有了运维意识之后，我能够知道当前我的设计需要快速上线、如何上线，我才能保证我的架构是增量式的。

第三，延迟非重要决策点，也是得益于社区今天所面临的工具是百花齐放。

第四，痛苦的事情提前做，这是敏捷里面最提倡的一点。当我们演进过程中，需要把交付流程里所有手动的过程尽量自动化，帮助我们弱化在这过程中一些痛苦的事情，比如说持续集成、持续交付。

这幅图是在微服务架构领域里非常经典的几个例子，包括像Netflix，这是他们在三到五年之中对架构的结果，这张图需要多少架构师设计出来？所以我的架构更多的是通过监控、告警，能够把当前运行的状态快照出来，这是未来的架构演进的方式。所以这三点是我对微服务架构包括我们在架构层面演进的理解。

三、微服务架构的生态系统

四、微服务架构的工程实践

最后是微服务架构的工程实践。这是 Netflix 从09到16年七年时间，把他的业务从数据中心迁到 AWS 之后的架构图。对于我们的系统而言，是不是意味着当我们把架构拆分成50个、100个之后，也能获取到这样收益呢？

这是很多组织和团队在做微服务的时候考虑的第一个问题。如果我们把架构拆成50个，100个，是否能获得同样的收益？答案是否定的。Netflix 首席云架构师说过，他们做了大量的关于流程工具和实践的演进。

五、总结

原创：王磊

前言

从2014年开始，当我接触微服务之后，我发现在微服务的演进过程中，开发和测试、运维需要相亲相爱，紧密合作，才能取得理想的效果。

本系列文章主要包括三部分内容：

第一部分：微服务与 DevOps；

第二部分：微服务生态系统；

第三部分：微服务架构的工程实践；

我在2014年的时候接触到一个海外项目，当时客户希望用微服务架构、DevOps、持续架构来做数字化转型。

经过一年多的时间，我们将客户的核心业务拆分成几十个服务，并对持续交付、团队组成做了很多的改进，带来的效果是显著的，从原有的四个月的交付周期，提升到随时按需发布。

在2015年底的时候，我出版了国内第一本关于微服务架构相关的中文书籍，叫《微服务架构与实践》，同时我也是《DevOps Handbook》的中文译者之一。

一 、什么是“微服务”

微服务这个词从2013年开始在社区兴起，这是去年的国外一个比较活跃的开发者社区，对2000多家企业包括北美的、欧洲、亚太的做的调研报告。

在这份报告里提到，已经接近30%的企业在使用微服务架构，而15%的企业目前正在试验开发和测试微服务架构。剩下的24%的企业正在积极学习和拥抱微服务架构。

从这个数据来看，随着应用系统变得越来越复杂，我们的交付周期变得越来越短，市场的不确定性越来越高，微服务架构正在成为帮助我们提升应用架构层面的核心竞争力。

这篇文章是 Martin Fowler 在2014年在他的博客上定义的什么是微服务架构。

我们过去的软件都是单体应用，就是指虽然在架构设计上将应用分层。比如典型的三层架构。

对于这类应用，虽然从逻辑层面上划分成多层，但是在运行层次上只有一个进程在运行程序，这就是单体应用。

而微服务架构是将单体应用拆分成多个小的服务，每个服务能够独立开发、更新和部署，同时服务之间能够通过轻量级的协议去做协作。

轻量级协议是指跟语言无关、平台无关的协议，今天我们在业界里面用得最多的 RESTful 协议就是。每一个服务都能够被独立部署到类生产环境、生产环境或者其他我们定义的环境。

在这个定义出来之后，在社区引发了很大争论，什么叫“小的服务”？我们怎么理解“小的服务”？

记得在2015年推特专门有一场争论是关于如何定义小服务，当时提出的建议是通过代码行来定义小的服务。

但是在今天所面临的社区是一个非常多元化的社区，我们有各种语言，面向对象的、面向过程的，面向函数式编程的，每一种是不一样的，所以很难决定我们的服务是不是够小。

第二点，很多人提出如果我的服务在很短时间内被重写，是不是认为应该算一个比较小的合适的服务呢？对于重写这个事情也有比较大的场景化。比如说我们的工程师对业务的理解、工具的熟悉程度，都会影响到我们来如何定义这个“小”。对于“小”的定义，我们很难清晰的描述一个标准来决定什么是“小”，但是在演进过程中，尤其是服务化过程中，在一开始我不建议划分成很细的服务，因为它会为我们带来很多后续的瓶颈。

最后是独立的部署，这也是在社区被很多人误解。对于软件开发而言，很多年以前一直在讨论模块化编程，因为我们有DAL等等，都是帮我们模块化软件的方式。但到了今天，随着业务变得越来越复杂，我们希望能够将需求实现尽快发布出去，让用户使用，所以就演变成能够把这些模块化再抽象一步，做成独立部署的单元。所以这是微服务架构跟过去很多软件开发里最大、最本质的区别之一。

除了 Martin 以外，还有很多大师做了很多解释。

首先，Fred George 也是很早定义微服务的人。他曾经就职于IBM，还为金融、保险提供过咨询服务，在2013年的印度敏捷大会上，他第一次讲到，他们将一百多万行的银行程序，使用了非传统 SOA 的方式构建，通过持续集成，将这个服务拆分成20个，50个，200个，最后实现交付周期从一年变成一周或者几天，这是最早对微服务的介绍。

第二个是 Adrian，他所在的公司是Netflix，做在线视频服务。在北美三分之一的网络视频流量是来自于这家公司，同时这家公司还制作了一部非常经典的美剧叫《纸牌屋》。在他过去的演进中提到从09年到16年，将原有的核心系统拆分成了600多个服务，同时做了很多的创新，尤其是在开源社区做了很多创新。他的架构师对他们过程的定义，所谓微服务是指：loosely coupled service oriented architecture with  bounded  contexts。

最后一位是 Neal，他认为微服务架构其实是 DevOps 演进之后的一种新的架构模式。

对于现在很多社区的概念，我们没有办法去给出一个标准化的定义，所以经常会说「一千个读者心中可能会有一千个哈姆雷特」。这是过去我基于自己的理解，对微服务的关键所做的新的阐述——所谓“微服务”是指以缩短交付周期为核心，基于 DevOps 所构建的演进式架构。

我们为什么要以持续缩短交付为核心？

这是在美国举办的架构师大会上的一段话，这是业界最先进的架构领域的大会，我们交付特性的速度已经落后于业务变化的速度，这成为阻碍发展和丧失核心竞争力的因素。

随着我们今天软件的世界变得越来越快，很多企业在面临如何去对用户做创新的过程中，交付的频率变得越来越高，我们如何提升我们的效率。

提到持续交付、缩短交付周期。从2010年《持续交付》这本书诞生以来，它已经开始改变我们对软件交付的理解。如果大家再去翻这本书的时候会发现，那时候这本书的作者已经提到，我们未来所交付软件的方式是希望能够：

第一，缩短我们的交付周期；

第二，能够降低我们在交付过程中的成本；

第三，能够将我们的质量内置在交付过程中的每一个环节。

如果我们打开软件交付的过程来看，其实发现过去很多方法论的提出，都与缩短交付周期有着密切的联系。从需求阶段最经常提的概念叫 MVP，所谓「MVP」是指我们定义需求的时候，先来分析最小、最有价值的需求，将这部分需求尽快上线，来满足用户的期望或者做试验，获取反馈之后再来进行改进，所以是从整体上缩短交付周期的。

之前我们谈到敏捷是讲快速建立反馈闭环，通过我们的 PDD，能够让开发人员或者测试人员更好理解，在这个需求的阐述过程中，如何能够有效实现它的特性。

当我们实现了敏捷，当我们实现了持续集成，开发人员已经完成了这个包的构建之后，下一步所面临的，我们如何将它部署到生产环境上，这就是我们解决的最后一公里的问题，它包括我们今天所讲的 DevOps，包括持续部署。

二、DevOps 是什么？

「DevOps」这个词最早诞生的出发点是希望能够解决软件在交付过程中最后一公里的问题。当我们已经构建了这个发布包之后，如何能够高效尽快将它上线，再往后是监控运营，有很多监控运营方式帮助我们收集用户的体验，核心目的是为了能够更快验证我们的想法，提升我们的交付效率。

但是在持续交付里有一个重要的能力模型，它里面包括持续集成、持续部署、环境管理、数据管理以及松耦合架构。

在过去的四五年期间，我发现在社区上除了松耦合架构以外，对于其他很多模块都有非常多的解决方案。比如说对于持续集成，在2011年的时候，我们开始帮客户做持续集成的方案，对于持续部署也有一些方案能够解决，同样对于环境管理，我们今天所讨论的发布，大部分都会有开发、测试、类生产和生产环境。

你会发现在过去的很长一段时间里，社区一直在讨论我们如何去更好构建持续交付的能力，但是如果我们回过头来想，我们在之前的这几个模块里已经做了足够多的优化，但是当我们的架构如果无法解耦，还是百万行千万行，我们怎么快得起来。

最早我在接触两百万行代码的项目里，一开始我们没有办法对架构立刻解耦，所以我们曾经花了将近五台服务器去构建一个持续集成，从以前的2个小时变成后来的20分钟，这是我们解决提升交付周期的方式。我认为微服务架构其实是从松耦合架构的角度考虑如何以持续交付，缩短交付周期为核心的解决方案。

为什么基于 DevOps？

开发人员的天性是希望能够用一些先进的语言，更高效的工具去实现我们的业务特性。但是对于运维人员，我们是保证生产环境能够准确无误的运行，所以这个协作过程中必然出现冲突。

我过去接触过一些项目，当开发人员完成代码的提交验证之后，这个包就放在代码仓库里，这时候开发人员需要做的很多事情是，我需要去定义一个清晰的部署步骤，交给运维同事用，再把这个步骤和当前运营的版本交给主管，主管会和运维主管协同协作，确定好之后再排期给真正部署运维的人员。

因为在一个企业里，运维团队都是稀缺资源，可能会负责公司很多产品的运维，所以这个过程中有大量的流程化手动的工作去完成部署，回到微服务架构我们想想，当我们把架构拆成多个可以被独立部署的单元的话，这个流程受到的冲击就非常大，所面临的挑战是很大的，所以对微服务与 DevOps 是相辅相成的。

在 DevOps 体系里，相信这两天大家听了很多关于 DevOps 的介绍，我再总结一下，对于 DevOps，我认为它的最大几个核心点，就是右边的这四个英文单词——CAMS。

自动化工具是我们重要的一环，有了工具可以使开发人员通过自服务方式完成部署。但是这过程中更重要的是，我们需要团队在开发运维之间更好的协作，让他们互相了解对方所做的事情。

比如说运维人员有丰富的运维经验，能够将这些经验传递给开发，开发人员可以根据他所理解的这些知识把这些脚本化或者工具自动化。同时对于部署过程而言，开发靠近分析，他更清楚我对这次部署的风险，能够跟部署人员做紧密协作，让部署提前考虑我部署过程中的风险。

同时通过一些监控度量和共享方式，促成 DevOps 的理念和实践的落地，这在整个微服务演进过程中是非常重要的。

什么是演进式架构？

在过去很多年里我们的概念一直认为，架构一旦被确定很难被改变，这是瀑布模型阶段性的影响。因为在瀑布模型里我们有很清晰的架构设计阶段、编码阶段和测试阶段，当我们的架构发生一点变化之后，对后面所带来的成本和反馈周期是非常大的，所以我们在前期对架构要做非常完美的设计，我们定义了一个方框，但是当开发团队在实现的时候，会做各种各样的妥协，因为我们所面临的很多需求在未来是不确定的。

对于过去，当我们只有一种技术栈，我们只需要定义企业的通用平台去满足各种各样的需求，但是对于市场变化莫测的时代，很难再去框这个框，这样对前期成本非常高，也不利于过程中的改进。

所以在社区里对于架构新的理念叫「演进式架构」，它所定义的是希望将敏捷的方式应用在架构层面，将增量式变更作为架构里面必要的一环。提到这个问题大家会想，对于架构而言，我怎么做增量式变更呢？

第一，我们一定要认为架构是对一个软件团队和成本的动态平衡，我们只有在演进过程中，和技术团队、成本、需求紧密结合，不断调整动态平衡。

第二，运维意识很关键。在过去演进过程中，通常是使用UML去画好架构图，但是在现代的架构快速演进的时代，当我们的服务超过一百个，两百个，三百个之后，是很难诠释微服务架构的。对于架构而言，更多的是对软件静态的抽象，是对当前软件运行的快照，所以对于架构师和我的团队而言，只有当我有了运维意识之后，我能够知道当前我的设计需要快速上线、如何上线，我才能保证我的架构是增量式的。

第三，延迟非重要决策点，也是得益于社区今天所面临的工具是百花齐放。

第四，痛苦的事情提前做，这是敏捷里面最提倡的一点。当我们演进过程中，需要把交付流程里所有手动的过程尽量自动化，帮助我们弱化在这过程中一些痛苦的事情，比如说持续集成、持续交付。

这幅图是在微服务架构领域里非常经典的几个例子，包括像Netflix，这是他们在三到五年之中对架构的结果，这张图需要多少架构师设计出来？所以我的架构更多的是通过监控、告警，能够把当前运行的状态快照出来，这是未来的架构演进的方式。所以这三点是我对微服务架构包括我们在架构层面演进的理解。

三、微服务架构的生态系统

四、微服务架构的工程实践

最后是微服务架构的工程实践。这是 Netflix 从09到16年七年时间，把他的业务从数据中心迁到 AWS 之后的架构图。对于我们的系统而言，是不是意味着当我们把架构拆分成50个、100个之后，也能获取到这样收益呢？

这是很多组织和团队在做微服务的时候考虑的第一个问题。如果我们把架构拆成50个，100个，是否能获得同样的收益？答案是否定的。Netflix 首席云架构师说过，他们做了大量的关于流程工具和实践的演进。

五、总结

原创：王磊