微服務

微服務（英語：Microservices）是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊 (Small Building Blocks) 為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關 (Lang而且複雜的服務背後是使用簡單 URI 來開放介面，任何服務，任何細粒都能被開放（exposed）。這個設計在 HP 的實驗室被實現，具有改變複雜軟體系統的強大力量。

2014年，Martin Fowler 與 James Lewis 共同提出了微服務的概念，定義了微服務是由以單一應用程式構成的小服務，自己擁有自己的进程與輕量化處理，服務依業務功能設計，以全自動的方式部署，與其他服務使用HTTP API通訊。同時服務會使用最小的規模的集中管理 (例如 Docker) 能力，服務可以用不同的程式語言與資料庫等元件實作^[1]。

概念

微服務的另一個對比是單體式應用程式。單體式應用表示一個應用程式內包含了所有需要的業務功能，並且使用像主從式架構（Client/Server）或是多層次架構（英语：Multitier architecture）（N-tier）實作，雖然它也是能以分散式應用程式來實作，但是在單體式應用內，每一個業務功能是不可分割的。若要對單體式應用進行擴展則必須將整個應用程式都放到新的運算資源（如：虛擬機器） 內，但事實上應用程式中最吃耗費資源、需要運算資源的僅有某個業務部份（例如跑分析報表或是數學演算法分析），但因為單體式應用無法分割該部份，因此無形中會有大量的資源浪費的現象。

微服務運用了以業務功能的設計概念，應用程式在設計時就能先以業務功能或流程設計先行分割，將各個業務功能都獨立實作成一個能自主執行的個體服務，然後再利用相同的協定將所有應用程式需要的服務都組合起來，形成一個應用程式。若需要針對特定業務功能進行擴充時，只要對該業務功能的服務進行擴展就好，不需要整個應用程式都擴展，同時，由於微服務是以業務功能導向的實作，因此不會受到應用程式的干擾，微服務的管理員可以視運算資源的需要來配置微服務到不同的運算資源內，或是佈建新的運算資源並將它配置進去。

雖然使用一般的伺服器虛擬化技術就能應用於微服務的管理，但容器技術 (Container Technology) 如 Docker 會更加地適合發展微服務的運算資源管理技術。

規劃

 

微服務中每個服務都能夠有自己的資料庫。

微服務的規劃與單體式應用程式十分不同，微服務中每個服務都需要避免與其他服務有所牽連，且都要能夠自主，並在其他服務發生錯誤時不受干擾。

 

如果資料庫都是分開的，那麼新服務上線時就會遇到資料庫為空的窘境。我們並不能從另一個服務複製資料過來，因為我們無法確定該服務擁有最新的資料。 此時應該從事件存儲中心重播所有事件，如此一來就可以找回先前的所有、最新的資料。

資料庫

微服務理念中有數個資料庫的規劃方式。

• 每個服務都各有一個資料庫，同屬性的服務可共享同個資料庫。
• 所有服務都共享同個資料庫，但是不同表格，並且不會跨域存取。
• 每個服務都有自己的資料庫，就算是同屬性的服務也是，資料庫並不會共享。

資料庫並不會只存放該服務的資料，而是「該服務所會用到的所有資料」。更深層一點的舉例：假設有個文章服務，而這個服務可能會需要判斷使用者的帳號⋯⋯等。那麼文章服務的資料庫就可以放入使用者的部分資料。此舉是為了避免服務之間的相依性，避免文章服務呼叫使用者服務。

資料庫的可棄性

實踐微服務有許多的做法，但其中一種做法是將資料庫作為短期的儲存空間而不是儲存長期的資料。這意味著資料庫可以在離線時被清空。因為它們可以在上線時從事件存儲中心恢复，因此也能以記憶體快取（如：Redis） 作為資料庫伺服器。但這種做法需要將每個請求當作事件來進行廣播。如此一來就可以從事件存儲中心重播所有的事件來找回所有的資料。

溝通與事件廣播

 

NSQ 是一個訊息佇列系統、平台。在微服務中所扮演的角色是將訊息、資料傳遞到其他服務。 此舉是異步執行，所以不需要等到其他服務接收到訊息就能夠執行下一步。這種方式能夠避免服務之間有所牽連、呼叫。

微服務中最重要的就是每個服務的獨立與自主，因此服務與服務之間也不應該有所溝通。倘若真有溝通，也應採用異步溝通的方式來避免緊密的相依性問題。要達到此目的，則可用下列兩種方式：

事件存儲中心（Event Store）

這可以讓你在服務叢集中廣播事件，並且在每個服務中監聽這些事件並作處理，這令服務之間沒有緊密的相依性，而這些發生的事件都會被保存在事件存儲中心裡。這意味著當微服務重新上線、部署時可以重播（Replay）所有的事件。這也造就了微服務的資料庫隨時都可以被刪除、摧毀，且不需要從其他服務中取得資料。

服務探索

單個微服務在上線的時候，會向服務探索中心（如：Consul）註冊自己的 IP 位置、服務內容，如此一來就不需要向每個微服務表明自己的 IP 位置，也就不用替每個微服務單獨設定。當服務需要呼叫另一個服務的時候，會去詢問服務探索中心該服務的 IP 位置為何，得到位置後即可直接向目標服務呼叫。

這麼做的用意是可以統一集中所有服務的位置，就不會分散於每個微服務中，且服務探索中心可以每隔一段時間就向微服務進行健康檢查（如透過：TCP 呼叫、HTTP 呼叫、Ping），倘若該服務在時間內沒有回應，則將其從服務中心移除，避免其他微服務對一個無回應的服務進行呼叫。

內容

一個微服務架構的應用程式有下列特性：

• 每個服務都容易被取代。
• 服務是以能力來組織的，例如使用者介面、前端、推薦系統、帳單或是物流等。
• 由於功能被拆成多個服務，因此可以由不同的程式語言、資料庫實作。
• 架構是對稱而非分層（即生產者與消費者的關係）。

一個微服務架構：

• 適用於具持續交付（Continuous Delivery）的軟體開發流程。
• 與服務導向架構（Service-Oriented Architecture）不同，後者是整合各種業務的應用程式，但微服務只屬於一個應用程式。

技术

微服务可以用不同的编程语言实现，也可以使用不同的基础设施。^[2]因此，最重要的技术选择是微服务之间的通信方式（同步、异步、UI集成）以及用于通信的协议（RESTful HTTP、消息、GraphQL……）。在传统系统中，大多数技术选择，如编程语言，都会影响整个系统。因此，选择技术的方法是完全不同的。^[3]

Eclipse基金会已经发布了开发微服务的规范——Eclipse MicroProfile。^[4]

Service mesh

在服务网格中，每个服务实例都与一个反向代理服务器实例（称为服务代理、 sidecar代理或sidecar）配对。服务实例和 sidecar 代理共享一个容器，容器由一个容器编排工具（如Kubernetes、Nomad、Docker Swarm、DC/OS）管理。 服务代理负责与其他服务实例的通信，并支持服务（实例）发现、负载平衡、身份验证和授权、安全通信等功能。

在服务网格中，服务实例及其sidecar代理被称为构成数据平面，其中不仅包括数据管理，还包括请求处理和响应。服务网格还包括一个用于管理服务之间交互的控制平面，这些交互由它们的sidecar代理协调。服务网格架构有几个选项: Istio、Linkerd、Consul和其他许多服务网格景观。服务网格管理平面Meshery （页面存档备份，存于互联网档案馆）提供跨服务网格部署的生命周期、配置和性能管理。

平台比较

实现微服務体系结构非常困难。任何微服务体系结构都需要解决许多问题（见下表）。Netflix开发了一个微服务框架来支持他们的内部应用程序，然后开放了^[5]该框架的许多部分。其中许多工具已经通过Spring框架得到推广——它们已经在Spring Cloud项目的保护伞下重新实现为基于Spring的工具。^[6] 下表显示了Kubernetes生态系统中的实现功能与Spring Cloud世界中的等效功能的比较。^[7] Spring Cloud生态系统值得注意的一点是，它们都是基于Java的技术，而Kubernetes是一个多语言运行时平台。

微服务	Spring Cloud与Netflix OSS	Kubernetes
配置管理：微服务应用程序的配置需要从代码中进行外部化，并可以通过简单的服务调用进行检索。	Spring Config Server、Netflix Archaius都支持基于Git存储库的配置位置。Archaius支持配置数据类型。	Kubernetes ConfigMaps通过服务公开存储在etcd中的配置。 Kubernetes Secrets支持基于服务的安全部署和敏感配置信息（例如密码，证书等）的使用。
服务发现：维护微服务域中可用于工作的服务实例列表。	Spring Cloud Eureka允许客户端向其注册，与注册的客户端保持心跳，并将服务名称映射到按服务名称查找服务的客户端的主机名。	Kubernetes Services提供集群内部可用的服务实例的部署时注册。Ingress是一种机制，通过这种机制，服务可以向集群之外的客户端公开。
负载平衡：扩展分布式系统的关键是能够运行一个组件的多个实例。然后要通过负载均衡器将负载分配到这些实例上。	Spring Cloud Ribbon为服务客户端提供跨服务实例负载平衡的能力。	Kubernetes Service提供了跨服务实例对服务进行负载平衡的能力。这与Ribbon提供的功能不同。
API网关：微服务提供的API的粒度通常与服务客户端需要的粒度不同。API网关实现表层，并提供其他服务，如代理、协议转换和其他管理功能。	Spring Cloud Zuul提供基于配置的API表层	Kubernetes Service和Ingress resources、Istio、Ambassador是提供南北（进出数据中心）和东西（跨数据中心或云或地区的通信）API网关功能的解决方案。
安全问题：许多安全问题推给API网关来实现。对于分布式微服务应用程序，不重新造安全方面的轮子，允许在所有服务共享的组件中进行策略定义和实现是有意义的。	Spring Cloud Security通过Spring Cloud Zuul解决了许多安全问题	Kubernetes生态系统提供了像Istio这样的服务网格，该网格能够通过其API网关机制提供安全性。
集中化日志记录：拥有一个集中化的日志收集和分析基础设施来管理大量的服务非常重要——其中许多服务是以分布式方式运行的。	ELK技术栈（Elasticsearch、LogStash、Kibana）	EFK技术栈（Elasticsearch、Fluentd、Kibana）
集中的度量：一个可以监控单个服务和整个系统的健康和性能的集中区域对于正确的操作是必不可少的。	Spring Spectator & Atlas	Heapster, Prometheus, & Grafana
分布式跟踪：每个进程的日志记录和度量监视都有其存在的地方，但它们都不能重构事务在跨分布式系统传播时所采用的复杂路径。分布式跟踪是微服务平台必不可少的工具。	Spring Cloud Sleuth	Hawkular, Jaeger
弹性和容错性：分布式系统必须能够围绕故障进行自动路由，并且能够将请求路由到提供最佳响应的服务实例。	Spring Hystrix, Turbine, & Ribbon	Health check, service meshes (example: Istio)^[8]
自动伸缩和自我修复：分布式系统通过水平伸缩响应更高的负载: 平台必须检测并自动响应这些条件。此外，系统需要检测故障，并尝试自动重启，无需操作员输入。	-	健康检查、自我修复和自动缩放
打包、部署和调度: 大规模系统需要健壮的包管理和部署系统来管理滚动部署或蓝绿色部署，并在必要时进行回滚。调度程序帮助确定可以根据当前条件将一组新服务部署到哪个特定的执行节点。	Spring Boot, Apache Maven. Spring Cloud系统没有真正的调度程序。	Docker, Rkt, Kubernetes Scheduler & Deployment, Helm^[9]
作业管理：控制无人值守的后台程序执行。	Spring Batch	Kubernetes Jobs与Scheduled Jobs
单例应用程序：限制特定服务作为该服务在整个系统中的唯一实例运行。	Spring Cloud Cluster	Kubernetes Pods

相關程式語言

• Jolie（英语：Jolie (programming language)）^[10]

微服務採用者

• Akana
• Amazon
• AnyPresence JustAPIs^[11]
• Apprenda^[12]
• Axway
• 1060 Research Ltd. （页面存档备份，存于互联网档案馆）
• Bluemix
• Cloud Foundry^[13]
• Google
• The Guardian
• Hailo Taxi
• HP Helion Development Platform
• Jelastic
• Microsoft Azure
• Netflix^[14]
• Nirmata （页面存档备份，存于互联网档案馆）^[15]
• nearForm （页面存档备份，存于互联网档案馆）^[16]
• Riot Games
• SoundCloud
• Uber
• Joined Node （页面存档备份，存于互联网档案馆）

平台實作

• Apache ServiceComb （页面存档备份，存于互联网档案馆）
• Docker （页面存档备份，存于互联网档案馆）
• Microsoft Service Fabric （页面存档备份，存于互联网档案馆） (overview （页面存档备份，存于互联网档案馆）, blog announcement （页面存档备份，存于互联网档案馆）)
• MicroService4Net （页面存档备份，存于互联网档案馆）
• NetKernel^[17]
• Nirmata （页面存档备份，存于互联网档案馆）
• Seneca Microservices Framework and Protocol （页面存档备份，存于互联网档案馆）
• Spring Cloud （页面存档备份，存于互联网档案馆）
• 微服務測試工具：Wilma^[18][19]
• Vert.x^[20]
• Baratine （页面存档备份，存于互联网档案馆） ^[21]
• KumuluzEE^[22]
• Enduro/X

參考

1. Microservices: A definition of this new architectural term. [2016-03-18]. （原始内容于2018-02-14）. 
2. Microservices Testing Strategies, Types & Tools: A Complete Guide. Simform. [2021-06-29]. （原始内容于2021-06-29）. 
3. Wolff, Eberhard. Microservices - A Practical Guide. 2018-04-15 [2021-10-01]. ISBN 978-1717075901. （原始内容于2021-05-01）. 
4. Swart, Stephanie. . projects.eclipse.org. 14 December 2016 [2020-07-20]. （原始内容存档于2022-01-19）. 
5. Netflix OSS, Git Hub, [2020-07-20], （原始内容于2021-05-01） 
6. , Spring, [2020-07-20], （原始内容存档于2022-06-22） 
7. Spring Cloud for Microservices Compared to Kubernetes, Developers (Red hat), 2016-12-09 [2020-07-20], （原始内容于2021-05-01） 
8. Managing microservices with the Istio service mesh, Kubernetes, May 2017 [2020-07-20], （原始内容于2021-05-01） 
9. The Kubernetes Package Manager, Helm, [2020-07-20], （原始内容于2021-05-01） 
10. . [2022-06-26]. （原始内容存档于2022-06-09）. 
11. . [2016-03-18]. （原始内容存档于2021-05-11）. 
12. How Enterprise PaaS can add Critical Value to Microservices. [2016-03-18]. （原始内容于2015-05-08）. 
13. Developing Microservices for PaaS with Spring and Cloud Foundry. [2016-03-18]. （原始内容于2021-05-01）. 
14. Microservices (PDF). ^{[永久失效連結]}
15. . [2016-03-18]. （原始内容存档于2021-04-13）. 
16. . [2016-03-18]. （原始内容存档于2016-03-26）. 
17. Products > Platform. 1060 Research Ltd. [12 October 2015]. （原始内容于2015-08-12）. 
18. . [2016-03-18]. （原始内容存档于2020-09-20）. 
19. . [2016-03-18]. （原始内容存档于2022-03-27）. 
20. . [2022-06-26]. （原始内容存档于2021-12-24）. 
21. Baratine. [2021-10-01]. （原始内容于2015-11-09）. 
22. . [2022-06-26]. （原始内容存档于2022-03-31）.