Microservices-The Journey So Far and Challenges Ahead

翻譯，原文出處——IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 2018

微軟服務是軟體服務設計，開發和交付的最新趨勢：
1. 它們構成了一種軟體和系統架構的方法，它建立在既定的模組化概念之上，但強調技術邊界。 每個模組、每個微服務都作為一個小而獨立的系統來實現和執行，通過一個良好定義的網路介面提供對其內部邏輯和資料的訪問.
2. 這增加了軟體敏捷性，因為每個微服務成為獨立的開發，部署，運營， 版本控制和縮放。

與SOA架構的關係

• 微服務是SOA的一個特定子型別。但是，儘管SOA傾向於強烈依賴諸如企業服務匯流排或其他類似重量級中介軟體的產品，但微服務僅依賴於輕量級技術。

• 其次，SOA通常與Web服務協議，工具和格式（如SOAP，WSDL（Web服務描述語言）和WS- *標準系列）相關聯。 相比之下，微服務通常依賴REST（Representational State Transfer）和HTTP4或其他被認為輕量級和本地化的Web開發格式。

• 最後，SOA被看作是一個整合解決方案，而微服務通常被用來構建單獨的軟體應用程式。

微服務的好處

• 交付速度更快：微服務通常採用輕量級容器技術打包並部署在雲中，遵循行業驗證的DevOps慣例，並由全自動化軟體整合和交付機制支援。這樣可以在多種執行環境中快速部署微服務（例如， 測試，分期和金絲雀版本），只需最低限度的集中管理

• 可擴充套件性更好：單個微服務是開發部署與執行的最小單元，在執行時，服務可根據其特定要求進行不同的擴充套件，同時每個微服務都可以由不同團隊開發，部署和運營，從而可以並行地引入新功能。

• 具有更大的自主權：每個微服務都可以提供一個獨立、受限的開發和執行時的決策單元，可以讓團隊自由選擇程式語言或實施策略的任何其他方面。

微服務演化

由SOA演化而來，SOAP切換到REST，更輕量和簡單的服務呼叫協議

技術角度

從2008年到2018年這十年間，有10個軟體技術的“浪潮”。在“微服務”這個詞被普遍採用之前，前五種技術浪潮已經存在——

• 第一波包含輕量級容器技術（例如LXC和Docker），這些技術允許在執行時更有效地打包、部署和管理各個服務。

• 第二波包括服務發現技術，它們讓服務彼此通訊而不明確地提及其網路位置。

• 第三波包括監測技術（例如Graphite和Sensu），這些技術可以執行時監控和分析不同細節層次的微服務資源的行為。

• 第四波包括容器編排技術（例如Mesos和Kubernetes），它們實現了容器分配和管理任務的自動化，抽象出底層的物理或虛擬基礎架構。

• 第五波包括延遲和容錯通訊庫（例如Finagle和Hystrix），它們使服務能夠更加高效和可靠地進行通訊。

其他五個浪潮是為了響應微服務的日益普及而出現的——

• 第六次浪潮包括持續交付技術（例如Ansible和Drone），它們提供通用整合解決方案，以自動化網路規模微服務生產環境中的DevOps實踐。

• 第七次浪潮包括混沌工程技術（例如Simian Army和Chaos Toolkit），它可以自動執行關鍵的全系統可靠性和安全測試技術，例如故障和攻擊注入。

• 第八個浪潮包含邊車（sidecar）技術（例如Prana和Envoy），它封裝了與通訊相關的功能，如服務發現和使用協議特定和容錯通訊庫，以便從服務開發人員中抽象出來。

• 第九波包括的無伺服器(serverless)計算技術（例如，AWS Lambda和OpenWhisk），該模型實現了FaaS雲模型。交付生產更精細的服務功能或功能，而無需建立和管理（例如，應對不一致的流量模式）執行所需的基礎設施資源的複雜性。

• 第十波包括服務網格技術（例如，Linkerd和Istio），它們建立在邊車技術基礎之上，以提供完全整合的服務到服務通訊監視和管理環境。

架構角度

微服務架構的四代更迭——

• 第一代：單個服務使用輕量級容器包裝，使用容器編排工具執行時部署和管理；但每個服務都要負責自己跟蹤其他服務的位置並進行失敗處理。

• 第二代：引入服務發現和可重用的容錯通訊庫，但通訊庫的語言限制了服務的編寫語言。

• 第三代：引入標準的服務代理/邊車作為一個透明的服務中介。

• 第四代：這個想法是利用最近的FaaS和AWS的Lambda等無伺服器-計算技術來進一步簡化微服務的開發和交付。有了這種無伺服器架構，微服務應用程式將基本上變成短暫的功能的集合，每個功能都可以根據需要快速隨意建立、更新、替換和刪除。

未來挑戰

• 服務的模組化與重構：如何劃分模組、分配職責、設計介面

• 服務粒度：不同的專案團隊對於微服務的大小規模意見不一致，缺乏統一的標準

• 前端整合：通常是一個巨石的前臺使用大量的後臺的微服務體系，這導致所有單體體系結構的缺點依舊存在

• 資源監控和管理：資訊太多，無法做出及時的管理決策；如何定義一個準確的警告閾值、資訊過濾——利用資料探勘、控制理論和機器學習從歷史事件中學習

• 故障、恢復和自我修復

• 組織文化和協調