决战云时代--“微服务”连接企业级应用(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）