微服務由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等無伺服器-計算技術來進一步簡化微服務的開發和交付。有了這種無伺服器架構，微服務應用程式將基本上變成短暫的功能的集合，每個功能都可以根據需要快速隨意建立、更新、替換和刪除。

未來挑戰

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

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

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

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

• 故障、恢復和自我修復

• 組織文化和協調

原文出處——IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 2018
譯文：https://blog.csdn.net/blanchedingding/article/details/81006371