微服务 Micro services

微服务 (Microservices) 是一种软件架构风格，它是以专一于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。微服务架构运用于软件架构风格的其中一项概念是甘露运算 (Dew Computing)，意指由许多的小露水 (表明微服务的功能元件) 聚集而成的运算能力。

微服务的起源是由 Peter Rodgers 博士于 2005 年度云端运算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有相似的前导想法，将类别变成细粒服务 (granular services)，以做为 Microsoft 下一阶段的软件架构，其核心想法是让服务是由相似 Unix 管道的存取方式使用，并且复杂的服务背后是使用简单 URI 来开放界面，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具备改变复杂软件系统的强大力量。

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，本身拥有本身的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其余服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务能够用不一样的编程语言与数据库等元件实做。

概念

微服务是一种以业务功能为主的服务设计概念，每个服务都具备自主运行的业务功能，对外开放不受语言限制的 API (最经常使用的是 HTTP)，应用程序则是由一个或多个微服务组成。

微服务的另外一个对比是单体式应用程序。单体式应用表示一个应用程序内包含了全部须要的业务功能，而且使用像主从式架构 (Client/Server) 或是多层次架构 (N-tier) 实做，虽然它也是能以分散式应用程序来实做，可是在单体式应用内，每个业务功能是不可分割的。若要对单体式应用进行扩展则必须将整个应用程序都放到新的运算资源（如：虚拟机器） 内，但事实上应用程序中最吃资源、须要运算资源的仅有某个业务部分（例如跑分析报表或是数学算法分析），但由于单体式应用没法分割该部分，所以无形中会有大量的资源浪费的现象。

微服务运用了以业务功能的设计概念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能都独立实做成一个能自主执行的个体服务，而后再利用相同的协定将全部应用程序须要的服务都组合起来，造成一个应用程序。若须要针对特定业务功能进行扩充时，只要对该业务功能的服务进行扩展就好，不须要整个应用程序都扩展，同时，因为微服务是以业务功能导向的实做，所以不会受到应用程序的干扰，微服务的管理员能够视运算资源的须要来配置微服务到不一样的运算资源内，或是布建新的运算资源并将它配置进去。

虽然使用通常的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 会更加地适合发展微服务的运算资源管理技术。

规划

微服务中每一个服务都可以有本身的数据库。

微服务的规划与单体式应用程序十分不一样，微服务中每一个服务都须要避免与其余服务有所牵连，且都要可以自主，并在其余服务发生错误时不受干扰。

若是数据库都是分开的，那么新服务上线时就会遇到数据库为空的窘境。咱们并不能从另外一个服务复制资料过来，由于咱们没法肯定该服务拥有最新的资料。 此时应该从事件存储中心重播全部事件，如此一来就能够找回先前的全部、最新的资料。

数据库

微服务理念中有数个数据库的规划方式。

• 每一个服务都各有一个数据库，同属性的服务可共享同个数据库。
• 全部服务都共享同个数据库，可是不一样表格，而且不会跨域存取。
• 每一个服务都有本身的数据库，就算是同属性的服务也是，数据库并不会共享。

数据库并不会只存放该服务的资料，而是“该服务所会用到的全部资料”。更深层一点的举例：假设有个文章服务，而这个服务可能会须要判断使用者的帐号⋯⋯等。那么文章服务的数据库就能够放入使用者的部分资料。此举是为了不服务之间的相依性，避免文章服务呼叫使用者服务。

数据库的可弃性

实践微服务有许多的作法，但其中一种作法是将数据库做为短时间的储存空间而不是储存长期的资料。这意味着数据库能够在离线时被清空。由于它们能够在上线时从事件存储中心回复，所以也能之内存快取（如：Redis） 做为数据库服务器。但这种作法须要将每一个请求看成事件来进行广播。如此一来就能够从事件存储中心重播全部的事件来找回全部的资料。

沟通与事件广播

NSQ 是一个讯息伫列系统、平台。在微服务中所扮演的角色是将讯息、资料传递到其余服务。 此举是异步执行，因此不须要等到其余服务接收到讯息就可以执行下一步。这种方式可以避免服务之间有所牵连、呼叫。

微服务中最重要的就是每一个服务的独立与自主，所以服务与服务之间也不该该有所沟通。假若真有沟通，也应采用异步沟通的方式来避免紧密的相依性问题。要达到此目的，则可用下列两种方式：

事件存储中心（Event Store）

这可让你在服务丛集中广播事件，而且在每一个服务中监听这些事件并做处理，这令服务之间没有紧密的相依性，而这些发生的事件都会被保存在事件存储中内心。这意味着当微服务从新上线、部署时能够重播（Replay）全部的事件。这也造就了微服务的数据库随时均可以被删除、摧毁，且不须要从其余服务中取得资料。

讯息伫列（Message Queue）

这令你可以在服务丛集中广播消息，并传递到每一个服务中。具备这个功能的像是 NSQ 或是 RabbitMQ。你可以在 A 服务上广播一个“创建新使用者”的事件，这个事件能够顺便带有新使用者的资料。而 B 服务能够监听这个事件并在接收到以后有所处理。这些过程都是异步处理的，这意味着 A 服务并不须要等到 B 服务处理完该事件后才能继续，而这也表明 A 服务没法取得 B 服务的处理结果。与事件存储中心近乎类似，但有所不一样的是：讯息伫列并不会保存事件。一但事件被消化（接收）后就会从伫列中消失，这很适合用在像发送欢迎信件的时机。

内容

一个微服务架构的应用程序有下列特性：

• 每一个服务都容易被取代。
• 服务是以能力来组织的，例如使用者界面、前端、推荐系统、帐单或是物流等。
• 因为功能被拆成多个服务，所以能够由不一样的编程语言、数据库实做。
• 架构是对称而非分层（即生产者与消费者的关系）。

一个微服务架构：

• 适用于具持续交付 (Continuous Delivery) 的软件开发流程。
• 与服务导向架构 (Service-Oriented Architecture) 不一样，后者是整合各类业务的应用程序，但微服务只属于一个应用程序。

误解

微服务这个名词令许多人觉得是很是轻量、很是微小的，且觉得透过该理念实做程式就可以达到下列效果：

• 微服务很轻量。
• 程式码将会变得更加地简洁。
• 变得更简单、开发时程变短。
• 微服务处理的事情变得更单一。

但这些是误解，实际上：

• 因为服务是独立自主的（也称：真空性），除了须要可以有本身的一套执行方式外，还不该该仰赖另外一个服务。为此，服务内会有着与其余服务相同的逻辑，这也致使了服务并不轻量。这部分有两派说法，分别是在服务之间创建同套资源库、工具，但这可能致使额外的相依性存在。而另外一种说法则是传统地将程式码复制与贴上，这将避免相依性问题，但在全域修改时可能不易管控，须要分散管理。
• 微服务属于分布式系统的概念之一，程式码并不会所以变得简单、短少，反而有可能为了处理外来的事件而变得更多。
• 微服务须要额外处理事件的广播、甚至是分布式的错误回溯问题，这致使开发时可能会更加地复杂，且花上更多时间在处理错误上。
• 基于第一点误解，微服务为了自主有可能会跨域实做，如文章服务有可能会带有使用者服务的理念，因此在处理事情上并不会特别专注。