决战云时代--“微服务”连接企业级应用(SaaS)与云计算平台之间最后一公里

一、背景

Martin Fowler 在 2014 给出了“微服务”架构（microservice）定义，现以是国内软件产业界最火热的名词之一。无论是刚毕业的学生，还是做应用开发的工程师都想用微服务架构做系统。之所以火热，来源与云平台的日益普及。在云平台普及的浪潮中，企业一方面感受到云计算平台来带的便利和实惠，另一方面，云计算平台依然缺乏基础设施支持“高性能、高可靠、高可用、可伸缩”的企业级 SaaS (软件即服务) 应用。同时，要感谢 IBM 在多年在各大院校推广 SOA 架构与技术，更重要是这种火热客观反映了企业应用与云计算服务平台融合的急切心情。“微服务”架构作为企业级 SaaS应用在云平台落地的一种可行方案，无论是国内云平台巨头 ATH（阿里、腾讯、华为），还是亚马逊（AWS）或微软（Azure）外来竞争者，无不在意这潜在的万亿级别的企业应用市场；同样，银行、电信、行业应用软件提供商都期望利用日益普及的私有云基础设施为内部和客户提供面向服务的企业应用。这里的问题是：

“微服务”的一切都准备好了吗？

(1) 外来竞争者的优势。目前，云计算行业领头者开始进入中国。亚马逊带着它的以ELB为中心的“微服务”解决方案，微软云也支持Nginx plus的“微服务”解决方案，这些基于云的解决方案是否有效？应用效果如何？

(2) 国内巨头集体落后。从目前“微服务”架构（SaaS）解决方案资料来看，国内各大 IT 巨头 ATH 应该都在埋头练内功。显然，在“微服务”基础设施建设、基础设施的租用机制、“微服务”案例研究、实施咨询团队建设等方面与亚马逊还有一段距离。国内开发团队“概念热”的背后，差距在哪里？

(3) 开源软件研发成熟度缺乏。开源软件成熟度以成为一个软件架构影响力，以及技术在软件开发商中普及的重要标志。J2EE、MVC架构拥有大量成熟的开源产品，直接导致去“IOE”（IBM，Oracle，EMC）化的形成。微服务基础设施的开源软件有哪些？基础设施需要包括哪些组件？能进入产业应用吗？

(4) “微服务”架构与IBM倡导的面向服务的架构、OSGi等技术的区别与联系。“微服务”架构的核心竞争力是什么？谁会笑到最后？

直接回答上述问题似乎时机并不成熟。本文的目标就是努力收集现有资料和案例，从理论与工程实践的角度，探讨基于云平台，使用“微服务”架构构建基于云的企业级应用（SaaS）相关的话题。

二、方法

为了探讨“微服务”架构，我们采用层次模型收集、整理现有的一些资料，如下图：

（1）概念部分：主要收集微服务架构的起源与动机，试图从架构定义的角度，分析微服务架构的特点，以及对SaaS应用开发的价值；

（2）架构模式部分：主要收集微服务架构的应用场景、设计模式，工作原理，解释与揭示“微服务”架构开发与应用的方法论；

（3）基础设施建设部分：主要收集部分已知的微服务架构基础设施开源软件，研究它们的主要特性与支持微服务开发、部署的基础设施；

（4）开发、部署与运维部分：主要收集部分企业级应用的实施方案与应用案例，包括微服务架构在企业级应用（SaaS）软件开发过程、技术与运维方面的支持等。

从软件工程角度，SaaS不是一个新的软件种类，IBM在面向服务的架构中完善了很多年。而云平台的出现，容器技术的发展，直接推动了SaaS在云平台上的应用。SaaS与云的结合，则是一种全新的软件业态。探讨SaaS企业应用在云平台上的开发、运维与维护的过程、方法与工具具有现实意义。

尽管我们的工作是初步的，在国内也算是第一次从软件工程的角度，比较完整地探讨微服务架构在SaaS软件开发的相关问题。同时给入门者一些了解微服务架构的资源。

三、概念

1. 面向服务的架构

谈“微服务”架构，不得不提面向服务的架构（SOA）。这里先简单概述一下SOA，为 “微服务”架构做一些铺垫。

什么是面向服务的架构，Gartner 的 SOA 概念是：

| “Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands.”

SOA 仅是 IT 业务领域的设计泛型与准则这么简单？显然 IBM 并没这么想。20世纪初， IBM Webspere 系列产品可以算是攻城掠地，似乎只有 J2EE 才是企业级应用。这时 IBM 发现了一个更大的市场，企业急需business to business 的解决方案，以解决企业越来越多应用导致的重复开发投入与业务不一致，即流传最广泛 “信息孤岛” 的概念。凭借 SOA 概念，IBM 成功从给黄金矿工提供牛仔裤与铁锹的角色转为挣大钱的牧师角色（卖硬件与软件工具转为咨询服务）。其实，你不得不佩服 IBM 在企业市场的号召力，SOA 概念靠故事玩了十几年，开发了一大推产品，也没有给 SOA 正式的学术定义。在“面向服务的体系结构与企业体系结构”系列文章中说，我们发现“SOA 与企业的业务目标之间关系”，因此考虑定义是：

| “面向服务的体系结构是一种用于根据需要对资源进行关联的企业级 IT 体系结构。

| 这些资源被表示为与业务一致的服务，这些服务可以参与和包含到价值网、企业或业务线中，以满足业务需求。

| SOA 应用程序的主要结构化元素是服务，而不是子系统、系统或组件。”

这个定义与 Gartner 的定义是无区别的。但 IBM 以其为为美国国防部、财政部、联邦企业等做架构咨询的实力，提出要为全球企业从业务、应用程序、信息、技术四个架构视角描述服务治理、数据架构、服务质量管理、服务集成设施四个层次的 SOA 综合治理，形成从业务流程 -- 服务 -- 组件支持 三层一致的信息处理框架。这与 IBM 的产品线一致的，因为组件如J2EE多数在 IBM 平台上开发的，现在要做的事情就是如何定义软件服务的标准，如何使用这些服务支持企业业务流程。所以，从IBM SOA技术支持首页就介绍 XML RPC（= 微软 SOAP = Web Service），这规范了软件服务的提供标准，接下来就是如何管理这些服务（服务治理）。服务治理内容很多，从技术的角度包含三个基础设施（主打产品）：

服务发现与集成（Universal Description Discovery and Integration，UUDI）：服务仓库。服务在UDDI中心注册、用户查找并使用。IBM当年画的蓝图是全球服务注册中心哦！！！
业务流程执行语言（Business Process Execution Language，BPEL）：服务组合语言。通过组合服务，生成新的服务。各种服务组合要产生多少新应用！！！
企业服务总线（Enterprise Service Bus，ESB）：分布式中间件。这些注册的、组合的服务，包括传统消息、邮件API的都挂在一条总线上。随用随取，随时修改！！！

围绕这三个基础设施， IBM 构建了执行环境（WebSphere 系列服务器），IBM业务建模工具等等。这是都牛叉的愿景，颇具一统天下的气概。为了培养大量技术人才，IBM大学合作部在全国培养SOA技术人才，课程主要以案例为向导，包括 SOA业务规划，Web服务的开发，建模工具的使用，配置执行环境。

小结：传统 SOA 架构是以暴露业务的服务为元素，支持服务注册与发现、服务组合与总线部署的业务到业务的解决方案。以企业业务流程为中心的服务治理架构，解决方案堆栈结构如图（Mamdouh Ibrahim）[1]：

【SOA 建议阅读】

[1] Mamdouh Ibrahim. 面向服务的体系结构与企业体系结构. 2007. https://www.ibm.com/developerworks/cn/webservices/ws-soa-enterprise1/

该文的架构图非常重要，可以让读者了解企业架构建模的层次与方法，更加全面思考服务面向的信息管理。

[2] Bobby Woolf. SOA 治理简介. 2007 http://www.ibm.com/developerworks/cn/webservices/ar-servgov/

了解 IBM 服务治理的概念。这与基于服务 API 的治理概念不一样。

2. “微服务”架构

“简单”与“有效率”地解决问题，往往是创新的起点。JavaScript程序员为了跟方便与 web 应用服务器交互，提出了 JSON 和 Restful Service，竟然能和 IBM，微软等巨头主推的 Web Service 在市场上对抗，JAX-RS 和 JAX-WS 一样成为了重要的服务规范，说明必须相信程序猿用脚投票的力量。

2009年，Netflix开源软件在创建和发布管理云基础架构的软件上取得的成功，依赖 web 服务成功建立了高性能、可扩展、易于维护的视频服务应用[3]。说白了，就是将单体的应用程序（Monoliths），分若干带服务接口（RS或WS）的独立部件（可独立部署的进程）。利用API路由/网关（router/gateway）组件，与服务动态注册组件协作，选择使用在线（live）进程注册的服务。流视频应用程序的概念路由示例的架构图如下：

熟悉分布式技术的人对这个架构图一点也不会陌生。RMI也使用服务注册使用技术，Nginx也可以作为负载均衡，唯一疑惑的就是动态路由（dynamic routing）。这个图也能有些问题，但并不影响工作原理描述。API edge zone A中要调用Movie Service，通过动态路由就可以找到那些运行的Zone绑定到Service registry中的服务申明，然后选择一个服务实例实现服务。如果你将Zone看成一个Docker容器或虚拟机，它上面部署一个进程（可以多个），这个进程提供Movie Service服务。当Docker容器上线，这个进程注册并绑定服务，服务信息就加入路由选择列表；当Docker容器断线，Service registry将清除路由中注册项并通知API edge。这带来的价值是显著的，服务组件是热插拔的、服务能力是可伸缩的、产品是容错的、每个服务组件是可监控管理的，系统可以按组件持续交付（例如，交付一个docker镜像）与持续集成（是组件级别，不是代码级别），每个组件可独立测试，这些都是企业级应用需要的非功能性特性。它唯一的强制要求是一个产品必须拆解成若干独立部署的服务组件，再组成一个满足传统企业级应用架构技术需求的系统（产品）。

这是一个简单、高效且优雅的技术解决方案。微服务的架构由此兴起，直到2014年，Martin flower的博客[4]给出了大家认为满意的微服务（Microservice）术语定义，加上spring cloud 等放弃 SOA 和 OSGi，全力支持 “微服务” 决战 “云时代” 的企业应用开发，微服务架构成为云时代程序开发的新模式。

要理解 Martin flower 对 Microservice 定义[4]，看原文的图不一定直观，理解Netflix架构示例最直观。博客原文：

| “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

微服务是架构风格。架构风格是软件架构专业术语，研究软件的部件、部件接口，以及部件之间的关系。软件架构风格就是要回答三个问题：一个软件由哪些部件构成？每个部件暴露什么样的接口？部件之间通过接口相互通讯的通用模型是什么？
单个应用作为一组小的服务。一个软件产品的部件是应用（或组件），它的接口是一组服务，部件之间以轻量级进程间通讯，例如：无状态的Restful Service；
这些服务采用自动部署机制，且设计围绕业务能力且能无依赖的部署。如果你了解一点 docker 知识就能明白，一般docker容器中只装一个应用，随容器自动启动，且容易可自动化（编程）方式部署与监控。
最小化的中心管理。这些部件间不能直接通讯（即存在依赖），需要通过一个中心选择路由（Router+Registry）通讯，应用与注册中心是松耦合的；
这些部件或服务可以用不同语言编写，使用不同数据存储技术。

注：官网中文翻译略有一点缺陷。

Martin flower 非常厉害，在定义中抽象和隐藏了技术实现，但担心你不明白这个定义。第一个图就是说，我有一个仓库系统，其中服务很多但在一个程序中，其中查询库存是对互联网开放的，但库存管理使用者就几个人。为了提高查询性能，用传统方法就是仓库系统多进程部署，其实库存管理一个进程就足够了。使用“微架构”就是把仓库系统产品的管理库存和查询库存分为两个应用分布独立部署，这样就可以按业务服务能力部署应用多个查询应用，一个管理应用。因此， microservice 架构风格改变了传统 monolithic 程序开发模式。鉴于多数人不在意架构与架构风格的不同，以后就去掉风格两个字。

Martin flower 还担心你对“微服务”存在一些误解，解释了一些微服务的特点：

部件 vs 服务。部件（component）是可替换可独立升级的软件单位。这样，微服务的部件目前仅可能是：可执行的程序、docker镜像、动态库、服务中间件（如OSGi的bundle）才能算部件。部件之间通过网络（不是内存）通讯，考虑到通讯开销，所以部件发布的服务接口不宜细粒度；
按业务能力设计部件。一个软件产品如何划分部件呢？原则应该将服务能力不同分配到不同部件，这样才能按需部署；
产品不是项目。传统一个程序既是产品又是项目，现在一个项目不过是可部署的部件。产品则是部件的组合；
Smart endpoints and dumb pipes。不会翻译，大致意思不能采用 ESB 或 BPEL （见前 SOA 简介）这些复杂的协议实现进程间通讯。你可使用类似 Unix 管道理念组合带服务的部件。
去中心化治理。SOA服务并没有定义服务的载体，微服务的载体是应用。SOA为了弥合服务之间的不一致，复杂逻辑全在ESB，BPEL中，导致部件之间在中心耦合。现在的中心就是简单的动态 Router，其中没有业务逻辑或协议翻译。这样每个开发团队吃自己生产的狗粮（自己开发，自己测试）就好了。
基础设施自动化。如果每个部件都做成 docker 或虚拟机镜像，这些部件都是可编程启动的，启动后部件就将服务接口自动注入服务仓库，供 Router 调度。
关注服务的失效。断路器解决方案，监控
进化设计。都是可持续交付的了，还有什么可说呢。

理解这个定义你就大致明白使用 Nginx Plus 产品做“微服务”产品开发过程。动态 Router 的docker image已经准备好了，如果业务应用的docker images 也开发好，你的软件产品就上线运行了哦！

3.微服务 vs. SOA

Martin flower 指出微服务架构与SOA主张类似，但微服务的SOA是一种创新。Martin flower 直接攻击 SOA 的技术基础（UDDI，BPEL，ESB）的痛点，复杂性而低效。

SOA关注的核心问题是业务，业务流程与企业目标的实现，这是信息架构师关注的问题。“微服务”关注的核心问题是技术，企业级应用如何在云平台上部署。尽管微服务架构定义回避了具体技术（值得学习），但微服务的目标是软件架构设计师关注的问题，包括产品如何分解，在云环境下团队交付的部件是什么，如何持续集成，如何构建高性能、高可靠、高可用、伸缩性好的产品。

对比表格，我们可以看到微服务架构的创新性：

	微服务	SOA	备注
问题	云平台企业级应用的开发与部署	B2B的业务整合企业资源的整合
目标	高性能、高可靠、高可用、可伸缩等	新功能实现灵活的业务组合
基本部件	应用	服务
基础技术	Dynamic Router Live Service Register	UDDI，BPEL，ESB
通讯	Restful Service	Web Service
关注点	分布式技术	业务流程
服务治理手段	API路由	业务组合

因此，SOA与微服务架构交集不多。SOA与微服务架构谁能笑到最后很难讲。SOA也是全球 IT 精英十几年努力的成果，IBM在SOA架构中融入微服务的技术理念也不是不可能。自少 Martin flower 也不敢说 BPEL 与 ESB 缺乏应用场景，也不敢说微服务能解决 SOA 要解决的问题。

从企业应用务实角度，程序员的支持对架构的成功也是至关重要。

【微服务架构阅读】

[3] Rick Osowski. 微服务实战，第 1 部分: 微服务介绍. 2015. http://www.ibm.com/developerworks/cn/cloud/library/cl-microservices-in-action-part-1/index.html

理解微服务起源和概念的较好文章，但微服务是否小等真不敢认同。

[4] James Lewis,Martin Fowler. Microservices - a definition of this new architectural term, 2014. 博客：http://martinfowler.com/articles/microservices.html

一种新架构术语的定义-“微服务”。【中文翻译】

四、架构模式

模式（pattern）是软件设计师的设计准则，架构风格就必须讨论架构模式（Architecture Patterns）。使用面向对象的风格做软件设计，“四人帮”的 23 种面向对象设计模式至少要会用常见的 7-8 种，例如单实例、适配器、组合、职任链、代理、装饰等。分布式设计，C/S、P2P、分层架构、缓存等。

用关键词“SOA design patterns”搜索 IBM 红宝书(http://www.redbooks.ibm.com/)，IBM 在这方面做了很多努力。从开始的e-business集成技术[5]到企业服务集成解决方案[6],以及后来《SOA设计模式》。豆瓣书评介绍有85种设计模式。可以试想，要解决各种各样复杂的业务问题，85种模式够用吗？但 SOA 就是这样定位的。。。

1. Nginx 微服务架构参考模型

解决企业应用在云上的部署，这是纯技术架构方案问题。Chris Stetson 对使用 Nginx 和 Nginx plus 支持微服务场景的常见解决方案进行了总结[7]：

Proxy Model（代理模型）：基本模型，Nginx+ 作为 API gateway。在微服务中承担：
- 服务通讯中心点。包含处理“session-specific data”
- 动态服务发现。通常通过 Zookeeper 等配置服务器
- API gateway。这个模块可以用 lua 脚本扩展
Router Mesh Model（路由网格模型）：在基本模型上添加：
- 负载均衡。
- 服务间缓存。
- 微服务健康检测（断路检测模型）。
Fabric Model（编织模型）：在每个服务部件中嵌入一个 API gateway。这些 gateway 共享注册服务仓库
- 客户端路由模型。（通常用 Zookeeper 订阅实现）

处于篇幅的考虑，就没有配图。原文[7]图不错，但编织模型图不易看懂，详细文档中图就很清晰了。

2. Chris Richardson 微服务架构

Chris Richardson 建了网站 http://microservices.io 收集总结了微架构模式与最佳实践。他将微架构设计模式总结为：

核心模式
- 单体设计模式
- 微服务设计模式
部署模式
- 每个主机多个服务实例
- 每个主机单个服务实例
- 每个虚拟级单个服务实例
- 每个容器单个服务实例
- 无服务器部署
通讯模式
- API 网关
服务发现
- 客户端发现
- 服务端发现
- 服务注册
- 自注册
- 第三方注册
数据管理模式
- 每个服务一个数据库
- 服务共享数据库
- 事件驱动架构
- 事件源
- CQRS（命令查询责任分离）
- 事务日志跟踪
- 命令查询责任分离
- 数据库触发器
- 应用事件

3.微服务架构的思考

从个人偏好，Chris Stetson 的总结优于 Chris Richardson 对微架构的总结。看 Richardson 博客就像听一个项目技术经理经验谈，Stetson 缺点就是与 Nginx + 联系的太紧密，与 Martin flower 的定义偏差比较大。

从分布式计算的角度，“微服务”架构就是中介代理模式（Intermediary Agent Model，IAM），但这种模式在云环境SaaS中有自己的特点，并发挥了灵魂作用！这里，我们给出了“微服务”架构的核心模式：

这样，一个“微服务”产品由一些Units（按Martin flower术语）和 Brokers 构成。其中，每个Unit是可升级独立部署的应用，它提供一组服务供其他Units使用。Units之间能且仅能通过Broker实现进程间（IPC）通讯。部件分为服务客户与提供者两种角色，其中，服务提供者与broker之间存在服务提供能力感知，broker按一定策略选择当前存活者的服务。

尽管一个非常简单抽象的模型，但它描述了仅需要一个浏览器，网关，一个应用进程就可以构件一个最小“微服务”系统。

在这个模型下，我们并没有明确指出 Unit 的软件对象，它需要哪些能力。一个微架构系统中 Unit 与 broker 如何组合以应付复杂的应用环境。RPC和alive感知的实现等等。直观上，Richardson、Stetson 都是模式（IAM）的变体。

【面向服务设计模式阅读】

[5] Martin Endrei,al. Patterns: Service-Oriented Architecture and Web Services. 2004.http://publib-b.boulder.ibm.com/abstracts/sg246303.html?Open

[6] Martin Keen, al. Patterns: Extended Enterprise SOA and Web Services. 2006.http://publib-b.boulder.ibm.com/abstracts/sg247135.html?Open

【微服务模式阅读】

[7] Chris Stetson. Introducing the Microservices Reference Architecture from NGINX. 2016.https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/

该文指出，NGINX 在 Docker hub 提供了试用镜像，并给了微服务架构使用 Nginx 的 demo。这通常是了解“微架构”程序的起点。

[8] Chris Richardson. A pattern language for microservices. http://microservices.io/patterns/index.html

这是一系列博客，描述了微服务架构中常见的设计场景与设计方案。

五、基础设施建设

SOA 出现的年代云还没有出现，微服务则是针对云基础设施的解决方案，为 SaaS 层云基础设施提出了新的需求。

1. Cloud 服务基础设施概述

大家都知道，云计算基础设施分为 3 层，每层都有自己的基础设施。

IaaS，基础设施即服务。这层基础实施包括虚拟机、虚拟存储、虚拟网络，用户按需获取硬件与计算环境；
PaaS，平台即服务。这层基础设施包括容器（操作系统虚拟化）、共享数据库服务、共享缓存、云流程服务、云内容服务（CDN）等；
SaaS，软件即服务。这层基础设施？

SOA 产品与基础设施包括 UDDI，BPEL，ESB [9]，这些的确可以部署在云平台之上，但它们是否太重？对企业级应用价值是否足够？是否让费云资源？尽管没有答案，但各大云平台似乎用脚投了票。或者说，企业级云应用不太需要它们。

SaaS 层基础设施是什么？这正是微服务架构回答的问题。

2. SaaS 应用基础设施服务场景

当前，云本体（Could Native）[10]是一种新的应用开发风格，它鼓励在快速持续交付、有价值的开发领域采用的最佳实践。相关的原则是构建以软件交付与运维为核心的 12 要素的应用（12 Factor App），例如采用申明式的编程、管理与监控。12-Factor 为构建如下的 SaaS 应用提供了方法论：

使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。 12-Factor 分别是：

基准代码：一份基准代码，多份部署
依赖：显式声明依赖关系
配置：在环境中存储配置
后端服务：把后端服务当作附加资源
构建，发布，运行：严格分离构建和运行
进程：以一个或多个无状态进程运行应用
端口绑定：通过端口绑定提供服务
并发：通过进程模型进行扩展
易处理：快速启动和优雅终止可最大化健壮性
开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同
日志：把日志当作事件流
管理进程：后台管理任务当作一次性进程运行

这符合 Martin Flower 对微服务架构的定义的实施需求，也是软件架构设计与 SaaS 基础设施建设的指南。

3. 基于 SaaS 服务的云基础设施

（1）Netflix 的方案

Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件[11]包括：

Eureka:　服务注册发现框架
Zuul:　服务网关
Karyon:　服务端框架
Ribbon:　客户端框架
Hystrix: 服务容错组件
Archaius: 服务配置组件
Servo: Metrics组件
Blitz4j: 日志组件

Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。

（2）Nginx Plus

Nginx 是最早支持 12 Factor 应用的产品，其架构设计（Chris Stetson [7]）是按该准则描述了 Nginx 架构的应用。Nginx 技术框架如图：

（3） Spring Cloud

Spring 是 Java 应用开发支持最强大的社区之一。2014 年 Spring 宣布退出对 SOA 和 OSGi 的支持，全力支持微服务和 12 factor 应用。推出了 Spring Cloud

| provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state).

为开发者提供快速构建一些分布式系统的常用模式，包括：配置管理、服务发现、断路检测、智能路由、微代理、控制总线、会话令牌、全局锁、主机推举、部分式会话、集群状态服务等。其目标是对以下任务构建抽象层：

Distributed/versioned configuration（分布式/版本配置）
Service registration and discovery（服务注册与发现）
Routing（路由）
Service-to-service calls（服务-服务调用）
Load balancing（负载均衡）
Circuit Breakers（断路）
Global locks（全局锁）
Leadership election and cluster state（主机推举与集群状态）
Distributed messaging（分布式消息）

尽管上述任务场景都是微服务基础必须提供的服务，但是 Spring 团队不知道哪些开源架构会成为主流，也不知道在云环境中构建 SaaS 应用是否完备。于是，采用了东北菜“乱炖”的做法，把一堆认为可行的 Java 框架汇聚在一起，用十几个子项目围猎（Nginx的策略也是用动态模块围猎），鼓励开源开发者贡献，这些子项目包括[12]：

Spring Cloud Conig
Spring Cloud Netflix
Spring Cloud Bus
Spring Cloud for Cloud Foundry
Spring Cloud Cloud Foundry Service Broker
Spring Cloud Cluster
Spring Cloud Consul
Spring Cloud Security
Spring Cloud Sleuth
Spring Cloud Data Flow
Spring Cloud Stream
Spring Cloud Stream App Starters
Spring Cloud Task
Spring Cloud Task App Starters
Spring Cloud Zookeeper
Spring Cloud for Amazon Web Services
Spring Cloud Connectors
Spring Cloud Starters
Spring Cloud CLI

尽管 Spring 提供了一些案例，称为最不要脸的项目也不为过。如果你是开发者，如何选择？

（4）Cloud Foundry

Cloud Foundry 是 VMware 推出的业界第一个开源 PaaS 云平台。VMware 是 IaaS 最大供应商之一，它提出 9 个基础设施[13]，至于基础设施分类为 IaaS、 PaaS 与 SaaS 就管不了那么多了。

Router：服务节点选择设施
Authentication：授权设施
Cloud Control：服务节点生命周期管理设施
HM9000：仪表式服务节点监控设施
Application Execute（DEA）：服务实例管理设施
Blob store：应用程序包、镜像存储
Services brokers：服务代理
Message Bus
Logging and Statistics

Spring Cloud 也是部分支持它的，SaaS 与 PaaS 之间依赖是必然的，哪些基础设施属于 SaaS 是值得进一步探讨的话题。

（5）AWS

亚马逊作为全球最大的云基础设施供应商，显然需要从 DevOps 角度提供对微服务架构的支持。通过下图，你能知道哪些是 SaaS 的基础设施呢？

（6）阿里的开源项目 dubbo

作为国内最早，也是最接近 “微服务” 概念的编程框架，也是国内各大互联网企业用的最多的服务架构之一。说白了，“微服务”架构概念有没有，并不一定是重要的事情。而建立支持互联网需要的企业应用是万万不能缺的，所以需要分布式架构支持这种高可用、高伸缩的应用，并且简化编程工作的平台。

dubbo 算不算“微服务”架构？是与不是不重要，DUBBO这样描述自己：

| “DUBBO是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架”

给出的架构图[14]：

它支持服务的注册与动态发现，支持 web 服务的部分 Router 功能，支持申明式使用等等，。仅因为它的目标是 RPC，它的理念是服务治理（不是API的管理，尽管做了这些工作，甚至很细致），所以它仅把自己作为编程工具，支持层次架构程序，而不能作为独立基础设施使用。如果，dubbo 项目按微服务架构合理划分子项目，修改 Router 支持的工作模式（现类似 Nginx+ Fabric 模型），应该是“微服务”架构值得候选的基础设施。

阿里的开源项目有一些共性：优点：真正来源于项目实战，即用即解决问题。缺点，缺乏面向共性问题的抽象，应用场合狭窄。文字应该不是大问题，值得翻译才重要。国内开源要走入顶级开源项目，最大的问题就是抽象。雅虎 zookeeper 之所以能成为顶级开源项目，就是它在从服务器集群状态管理中，抽象出配置服务管理的基本模型。

期待国内“微服务”架构基础设施出现。。。

4. 三大数据结构服务，SaaS基础设施的基础设施

尽管每个开发社区有自己的微服务架构的理念，有自己对 SaaS, PaaS, IaaS 的理解，“动态服务发现+路由”是“微服务”架构的核心基础设施。个人认为，SaaS 的基础设施必须包括三大数据结构服务设施：

Redis，字典（map）数据结构，进程数据共享设施
RabbitMQ, 队列（queue）数据结构，进程消息通讯设施
Zookeeper，树（tree）数据结构，服务依赖配置、进程状态监控设施

这里直接采用产品名称不代表没有竞争产品，而是这三个产品既能单机部署也能集群部署，特别符合云 SaaS 应用的需要。离开任何一样数据结构服务，开发企业级应用几乎是不可能的。

【微服务框架与产品参考】

[9] 主流 SOA 厂商与相关产品. http://www.cnblogs.com/chnking/archive/2008/10/28/1321741.html

[10] Matt Stine. Migrating to Cloud Native Application Architectures. O'Reilly. https://pivotal.io/platform/migrating-to-cloud-native-application-architectures-ebook

该书是讲述云时代应用架构的第一本书，必读！！！

[11] 杨波, 实施微服务，我们需要哪些基础框架？ 2015. http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service

该文首先介绍了 SaaS 应用的需求，最后介绍了 Netflix 框架与组件

[12] http://projects.spring.io/spring-cloud/

[13] https://www.cloudfoundry.org/learn/features/

[14] http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-%E6%9E%B6%E6%9E%84

六、开发、部署与运维

如何开发、部署与运维？这方面资料似乎很少

1. SOA 的实施方法

IBM SOA 曾今出过一系列案例与文档讲述 SOA 的实施，例如： "SOA 案例研究：SOA 设计" 与参考文档（可惜，IBM红宝书网站打不开了）。IBM案例研究的套路是教科书式的，包括：识别问题与挑战、制定项目目标、业务场景（流程）分析、流程-服务-部件（分层结构）的映射、得到组件模型、业务建模工具与实施。这是典型的“RUP4+1”多视图架构（业务场景分析、逻辑设计视图、应用部署视图、组件开发视图、运维管理视图）分析方法。

请不要指责 IBM 当年没有提到 “高性能、高可靠、高可用” - “三高” 企业应用的构建。必须说明， IBM 当年面临的挑战是如何弥合许多单体程序产生的“信息孤岛”问题，如何构建灵活的信息系统业务服务是问题的重心。IBM 崇尚的理念程序员仅需要关注业务逻辑的实现（可能受 Java 影响太深），通讯、进程、性能等统统交给程序框架、系统工程师。IBM SOA 工具大抵如此，如支持 BPEL 等的图形设计支持工具。我坚信程序猿都不喜欢 IBM 建模工具，因为不仅是程序员有“失业”的感觉，关键是学习了半天服务整合技术，前后台整合工作量依在，几行代码的玩意变成了复杂的 XML 和满屏的框和线，最最关键是功劳却被 IBM 工具抢去了。领导关注的是大把美金换来的“银弹”，而不是程序猿的幸劳。

吐槽 IBM 是毫无意义的，今年它在云计算服务领域几乎没有地位，“微服务”也尽可能回避 SOA，但 SOA 积累的 “问题-目标-场景-流程-服务” 开发设计过程，目前仍然有它的应用价值。

2. 微服务架构的开发与部署

微服务架构应用开发与部署，Nginx是领头羊。随着 Python， Node.js 这些解释语言在 web 应用中日益流行，web 应用快速交付能力迅速提升。问题是解释性语言都无法突破全局数据锁问题，或者说与线程说 bye-bye。要提高web服务能力只有一个出路，每个程序做的很小（做大了也无法维护，类型检查都没有的），使用更多的进程。Nginx 的反向代理、web 缓存支持特别合适这类 “微程序” 组合而成的应用。“微服务”概念的提出，让 Nginx 看到了云时代自己的未来，很快就推出了收费的 Nginx plus（也符合企业应用支持扩展收费的习惯）。微架构设计、开发文章都是在 Nginx 的 Blog 上一点也不奇怪。

其中，Chris Richardson 写了七篇文章讲述了微服务概念、涉及的技术、设计准则、以及如何从单体程序迁移到微服务[15]:

介绍微服务
构建微服务：使用API网关
构建微服务：微服务架构与进程间通讯（IPC）
微服务架构与服务发现
事件驱动数据管理与微服务
选择微服务部署策略
用微服务重构单体程序

国内都有翻译，建议读者无论读完架构、框架或实施方法后，都需要重新阅读 Martin flower 的定义。如果讨论微服务代码行的问题明显与定义不一致，建议直接忽略，转而理解Martin 的服务能力，什么是基于能力的设计？ Martin flower 的背景是写过企业架构书的专家，SaaS应用的需要是非常清晰，使用术语可能专业了一些，但概念绝对清晰。

按 Martin flower 的定义，微服务是语言无关的。即任何提供 web 访问的程序都可以是微服务架构的程序，能否被网关 Router 则是技术问题。这里仅建议每个微程序都做成 Docker Image，然后做组合，这是目前最认可的最佳实践。

3. AWS 与 DevOps

Netflix 微服务架构在亚马逊 AWS 云落地，项目就部署了 500 多个微服务，与亚马逊 30多个开发团队。这大大提升了 AWS 在微服务架构开发与运维方面的话语权，也是最成熟的“微服务”架构运营服务解决方案供应商，而且也为租用云的用户开发了一些“微服务”需要基础设施供客户免费使用。由于微服务从 2014 年突然暴发，ATH（阿里、腾讯、华为）也只能哑火了。

InfoQ 短文介绍了 AWS DevOps 主管 Chris Munns 演讲“微服务与服务团队在Amazon的发展” 。尽管从今天看，有些观点不一定正确，但是客户有需求，我有案例，我就为你提供服务咨询。这里分享亚马逊咨询团队的一些中文 ppt ，让我们大致了解 AWS 面向微服务的服务。

亚马逊AWS上的微服务架构（张芸），其中大多数内容本文都有准确、详细的描述，这是分享的是 DevOps 与 “微服务”架构服务内容建设：

初创公司用AWS搭建高扩展性架构（张侠， CSDN 2015），全面介绍了AWS云服务设施与应用程序的关系。作者用了企业在7天内成长，描述了企业应用成长过程中对信息服务软件的需求，以及 AWS 对应的解决方案。对开发人员快速了解 AWS 基础设施和服务很有帮助。

4. 平台选择与其他

技术平台可选择的选择其实不多，大概就这些了：

Nginx plus：合适企业和需要了解“微服务”架构的人。Nginx上重要文档几乎都能找到中文翻译，技术要求少，能帮你理解工作原理与架构思路。普通用户就是试用一下，企业用户认为合适就购买就是了，开源服务一般不贵啊。
AWS：注册一个账号有 270 天试用，绝对大方，尽情测试和使用。即使你用开源微服务方案，AWS也是最好的云计算平台。
Spring Cloud：Java 技术爱好者的选择，集成了无数开源工具。

云平台选择：

目前国内云平台在微服务 DevOps 咨询服务方面都比较弱，用 Nginx plus 和 Spring Cloud 应该都都没问题。
阿里云栖社区发了在“在阿里云容器服务上开发基于Docker的Spring Cloud微服务应用”的文章。不过采用了 foo， bar 这些 Java 社区常用的类。对于“微服务”架构典型应用可能更容易大家接受，因为读者不可能是 Java 初级程序猿，架构理念远远重要于实现技术。

我们前面提到了 Dubbo，但它目前并不是“微服务”架构支撑设施，不建议选择。

【微服务应用开发、部署阅读】

[15] Chris Richardson. Introduction to Microservices, 2015-2016. 系列博客：https://www.nginx.com/blog/introduction-to-microservices/

该系列共7篇，分别是“介绍微服务”，“构建微服务：使用API网关”，“构建微服务：微服务架构与进程间通讯（IPC）”，“微服务架构与服务发现”，“事件驱动数据管理与微服务”，“选择微服务部署策略”，“用微服务重构单体程序”。

中文翻译： http://dockone.io/article/1266

[16]李斌. 在阿里云容器服务上开发基于Docker的Spring Cloud微服务应用. 2016. 系列博客：https://yq.aliyun.com/articles/57265

七、总结

“微服务”架构自有了定义后，其理念和观点得到产业界极大认同，这无疑将推动云计算环境 SaaS 服务基础设施标准化，使程序员更方便开发出满足云上可部署的企业应用架构需求（非功能性，包括高可靠、高性能、高并发、热插拔、可管理、易维护等）的应用，“微服务”架构将连接企业级应用(SaaS)到云平台的最后一公里。

“微服务”架构的概念属于云计算而不是SOA领域，因为目前文章大多数归类在“云计算”主题下。“微服务”架构会逐步成为云上企业应用编程、部署、运维的标准。其实，从Spring Cloud布局来看，也是期望推出一套 JCP（Java Community Process）认可的 JSR（Java Specification Requests）接口标准。得标准者得天下，大型社区得终极目标就是建立全球认可得标准。

“微服务”架构是技术架构概念，目前技术研发门槛是比较低的（相对对开源软件有二次开发能力的企业）。Osowski[3]指出"今年(2015)下半年和下一年将会引入到 IBM Bluemix 中的微服务功能"，体现了从 ESB 或Apache Camel 技术演化出 IBM 风格“微服务”架构工具的技术自信，Kim Clark[17] 甚至提出了敏感的对比问题。不过 IBM 这几年几乎没推出受程序员喜欢的玩意，在牧师的服务费与牛仔裤加工费面前，IBM 能在“微服务”架构下再次雄起吗？

“微服务”架构统一了概念，但在设计模式、基础设施建设、应用开发方法论方面，除了核心内容并没有统一标准，属于“群雄逐鹿”得年代，“鹿死谁手”？。。。

【微服务与SOA阅读】

[17] Kim J. Clark. 微服务、SOA 和 API：是敌是友？ 2016. http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1601_clark-trs/1601_clark.html