DockerInfo原文：Microservices in cloud-based infrastructure – Paving the way to the digital future
作者：Gunnar Menzel
目 录
简介
服务术语解释
微服务
微服务最佳实践
微服务和基础设施
微服务和基础设施设计原则
乐高积木方法
微服务基础设施 – 乐高积木蓝图
由此产生的概念模型
微服务基础设施 – 合理的实现步骤
总结
附录：参考文献
由于篇幅限制，本文后半部分将在下期推送。
简介
微服务需要一种新的基础设施构建方式：微服务意识（microservices-aware）必须遵循乐高积木方法。
一切事物都具周期性。早在 2005 年，我们讨论、定义、开发了基于面向服务架构（SOA）解决方案（2005 年 Capgemini 的 SOA 观点、论文、白皮书已经提出了「一切即服务」的概念）。如今，当被问及什么是一流的软件蓝图时，我们倾向于推荐微服务（2011 年 5 月，「微服务」一词最早由威尼斯附近的一个软件架构师小组提出）。两者都基于同一简单的概念：将设计和开发独立开来，基于效用的服务可以驱动并提供灵活性、安全性、敏捷性。我们正在从第二代平台过渡至第三代平台（第一代平台架构指的是主机时代（单体应用），第二代平台指的是基于 Client/Server 的运算，第三代平台是原生 Web 格局，用户可以在任何时间任何地方使用任何设备访问应用程序和数据）。在应用程序、数据、自动化为王的时代，越来越多的团队开启了「数字化」的格局。
10 年前推出的时候，微服务是设计和构建应用程序的方法之一，基于单体或 SOA 的方案都仍是合理的选择。然而，基于微服务设计的应用程序正在持续增长，特别是使用第三方平台功能的团队。微服务需要一种新的基础设施构建方式：微服务意识（microservices-aware）必须遵循乐高积木方法。由此产生了基础设施平台必须完全基于软件。这意味着，数据中心将由软件实现完全自动化，以便通过软件管理硬件、网络、存储配置。这与硬件和驱动定义基础设施的传统数据中心形成了鲜明的对比。
为了实现全面数字化，加快数字化进程，团队的基础设施布局必须遵循一套明确的设计模式，比如易用性、自助性、敏捷性和灵活性。然而，浏览所有相关项将会变得非常棘手，所以微服务将提供一些指引，本文的主要两个目的：深度分析微服务对基础设施产生的影响；调查如何设计如今基于微服务的基础设施。
服务术语解释
现在有相当多的专业架构术语，比如面向服务架构（SOA）、事件驱动架构，微服务架构和软件定义数据中心（SDDC）。一些常见的观点认为「服务」是业务、技术功能、物理产品或架构方法，并没有标准的定义。事实上，「服务」这个词根据不同的环境有许多抽象概念：
- （面向）服务架构：设计模式主要与企业架构及其业务、信息、信息系统和技术基础设施的整合方式相关。
- 业务服务：业务运营模式结合业务流程和业务事件，评估缩容价值的设计方式。
- 应用程序服务：通过各种技术解决方案和标准为「业务服务」提供应用程序支持（这是微服务主要涉及的领域）。
- Web 服务：通过标准的 Web 服务协议进行大量访问的特殊应用服务，特别是用以接受和返回 XML 文件，比如定义协议；但是普遍标准不同。
- 信息服务：通过各种技术解决方案和标准，实现为应用程序服务提供信息的设计方法。
- 基础设施服务：为应用程序、Web、信息服务提供支持的独享或共享的基础设施服务。
- 基于服务的方法主要是为了开发或构建能被应用在不同环境的细粒度功能。
微服务
微服务涉及的设计模式是一系列的独立应用程序服务使用独立，低耦合，自包含（没有外部依赖）的业务功能进行交付。遵循 SOA 的风格（见下文），微服务更自主、独立，比 SOA 更小或更细粒度。
微服务架构可以视为面向组件架构和面向服务架构结合的产物。软件是一套由负责各自具体业务领域的许多小型业务组件构成的系统。他们通过明确定义服务的 API 对外提供接口。
服务的所有权是微服务从 SOA 彻底脱离的一个方向：使用微服务，只需要一个团队或个人就可以开发和更新已有服务的代码，Netflix 就是使用这种模式的公司。微服务得以发展壮大是因为其彻底贯彻了 Eric Evans 的领域驱动设计 [1]- 因为其可以由小型的独立团队进行开发和维护。
低耦合的服务可以彼此独立更新；一组必须同时更新的服务并不能称之为微服务，因为其并非低耦合，这也适用于服务之间共享同一数据库的情况，更新一个特定的服务意味着改变整个模式（schema），或对共享模式（schema）的更新将牵动一个以上的微服务 – 称之为「反模式」。
微服务最佳实践
实用的基础设施服务是一个交付服务解耦的共享基础设施并支持先前定义的设计原则的计量服务。
如之前所说，微服务与 SOA 有许多共同之处。SOA 主要是关于「暴露」应用程序的离散组件，作为 Web 服务和基于 SOA 的应用程序包含由适用于不同环境的更低耦合的组件。SOA 是从第一代平台过渡到第二代平台的关键模式，微服务是团队迁移至第三代平台的关键。
持续开发和提供基于微服务应用程序的详细定义，不在本文的讨论范围之内。然而，理解基础设施架构布局需要遵从什么特性以支持基于微服务的应用程序，定义微服务的设计原则非常重要。微服务的关键设计标准都与服务说明有关。
「好的」微服务：
1、拥有无状态（无状态在特定的体系架构中越来越罕见。2015 年 Strange Loop 上有一则关于有状态微服务的演讲。无状态所以无法确定什么是「微服务」。然而，除非绝对必要，需要避免这种想法）且「愚蠢」的细粒度功能。
2、拥有定义明确的用于隐藏服务如何运行的接口（也就是说，我只关心接口，而不是服务是如何在内部运行）。
3、使用低耦合方法（某个服务的更新不会影响其他服务）。
4、「一次性的」、「脱离 ESB（企业服务总线）」、「笨水管和智能服务」。
5、自主、明确版本、高度独立。
6、简单思考，即「专注做一件事，并做到极致」。
7、明确的成本和价值定义。
遵循这个设计原则引出基于微服务的架构风格；开发和实现基于微服务的应用程序，必须覆盖方方面面。从基础设施的角度来说很重要的一点是，基于微服务的应用程序必须要遵循基于效用的方法，对于微服务来说意味着基础设施需要「隐形」。基于效用的基础设施服务的交付物是封装后的基础设施资源，相当于传统公共服务（如电、水、天然气、电话网络）的计算、存储、数据传输、类似于计量服务等。换句话说，实用的基础设施服务是一个交付服务解耦的共享基础设施并支持上述定义的设计原则的计量服务。
微服务和基础设施
为了实现微服务，底层基础设施性能必须支持微服务的设计模式，并专注于所有相关的非功能性特征（可用性、稳定性、可靠性、性能和安全）。微服务需要开箱即用并可以使用「乐高积木」方法构建的基础设施 [2]。
基础设施相关能力如计算、存储、网络，和基础设施相关功能如负载均衡、主从复制等一样，必须遵循「即插即用」的方法，并且微服务的实现必须是透明的。
透明的关键推动者显然是「云」。采用云基础设施的方法，将加速基于微服务应用程序的实现。
软件模式和相关基础设施建设蓝图的基础设施，更准备地说是技术基础设施，是所有在特定的环境通过信息系统（应用程序）对使用或消费的数据进行存储、处理和传输的技术组件的组合；有一定的性能特征和一系列所谓的非功能性需求。
为了构建「隐形」的微服务，基础设施服务必须符合特定的特征。走近细看，这意味着微服务开发人员不仅必须拥有构建、使用、迁移、扩容、缩容、删除和计算的能力，还需要有网络和存储能力。这包含所有客户面临的基础设施服务。就像融合、超融合和全融合的基础设施（或更好的软件基础）使用私有云、公有云或混合云部署或备份概念，这将是很多团队使用微服务的模板。
微服务和基础设施设计原则
基于微服务的基础设施平台必须软件化。这意味着将由软件实现数据中心的全自动化，以便通过软件管理硬件配置、存储供给，网络配置。这与通常使用硬件和驱动管理，需要手动操作进行更改基础设施的传统数据中心不同。
附录：参考文献
[1] Eric Evans，2003，《领域驱动设计：软件核心复杂性应对之道》；Capgemini 2005，面向服务的企业：如何使业务快速、灵活、响应
