當前，DevOps、平臺即服務(Platform-as-a-Service)、容器和持續集成及交付(CI / CD)等等一系列的方法讓現如今的企業組織得以以前所未有的規模創建和管理他們的模塊化系統。盡管重構整體單片App應用程序在不同程度上獲得了成功，但是，建立微服務架構可能會是企業組織的一項重大的投資，并且無法立即獲得立竿見影的投資回報。

在本文中，我們就將為廣大讀者朋友們介紹關于如何通過逐漸重構您企業的應用程序來實現微服務的成功。同時，我們還將為您介紹如何構建您企業微服務的基礎，以改進面向服務的架構，以及如何從易于開發和維護、應用程序組件獨立的可擴展性等方面受益。

微服務架構是創建松散耦合但卻是自主服務的一種新的架構形式。諸如DevOps、平臺即服務(PaaS)、容器以及持續集成及交付(CI / CD)方法等新興的技術趨勢讓現如今的企業組織得以以前所未有的規模創建和管理如面向服務的架構(SOA)這些模塊化系統。盡管重構整體單片App應用程序在不同程度上獲得了成功，但有效使用微服務的關鍵則在于企業組織如何以及為什么應該使用微服務來構建應用程序。

改進以服務為導向的架構

面向服務的架構(SOA)通常被定義為通過網絡向其他組件提供服務的應用程序組件。而SOA的目標是創建彈性分布式的應用程序，而不需要復雜的集中式組件。

然而，SOA與組織結構是密切相關的，并用于支持新的內部結構。因此，其成功高度依賴于由此而來的重組的組織架構能力及設計架構的團隊的結構。SOA并不是創建松散但卻自主的耦合系統，而是創建了需要復雜基礎架構的高度脆弱的系統。此外，早期的SOA實現創建了供應商鎖定，因為專有的中間件通常集中于集成整合的邏輯化的、持久性的管理領域。

微服務體系架構最初是始于在構建應用程序(從開發到部署再到運營)的每個步驟方面的SOA承諾。微服務體系架構側重于簡化技術，以構建具有流線型組件的復雜系統。基于重量級的、非標準化平臺的集中式邏輯和集成基礎架構被由基于異步HTTP或消息協議的簡單標準化渠道所代替。SOAP、XML和其他重量級協議和數據格式由基于HTTP的REST的輕量級JSON語言所替代。每款微服務都有其自己的數據存儲，而不需要集中式的管理和持久性。

微服務使用持續集成(CI)和連續交付(CD)的方法和實踐方案，以及在SOA中不常見的幾大關鍵組件，例如：

Polyglot編程和持久性。

容器或不可改變的虛擬機(VM)。

彈性的、可編程的基礎架構即服務(IaaS)和PaaS。

一款靈活、IT響應靈敏的創新解決方案

1、更快的部署

微服務的范圍較小，這取決于對域邊界和一致性域建模的關注，并且需要較少的代碼。部署策略包括專門集中式的自包含的存檔(通常以Linux容器和CI/CD打包封裝)可以實現更快、更可靠的部署。因此，軟件開發生命周期通常變得更快。新功能和錯誤bug修復以及經過完全測試的安全修補程序都將得以實現更迅速的發布。

2、模塊化的控制

借助微服務，每項服務可以實現獨立的擴展，以滿足臨時性或季節性的流量增加，完成批處理，并滿足其他業務的需求。改進的故障隔離限制了服務問題，如內存泄漏或數據庫連接打開，僅影響該特定的服務。微服務的可擴展性補充了云服務的靈活性，讓您企業得以改善服務，同時在不中斷服務的同時處理更多的客戶服務需求。

更多的選擇

開源技術解決方案和組織化的方法正在引領微服務市場。由此，微服務可以減少供應商鎖定，并消除長期的技術承諾，讓企業客戶得以能夠選擇滿足您企業特定IT和業務目標所需的工具。

為微服務建立堅實的基礎

想要實現微服務的成功，企業組織就必須首先為其整體架構創造堅實的基礎。還必須考慮和建立模塊化、域邊界和基本的分布式系統理論，以實現微服務的全部優勢。

此外，微服務為更復雜的系統創造最大的益處。雖然每項服務都是完全獨立的，但是必須滿足操作要求，這包括以下功能：

DevOps。

PaaS。

容器或不可變的虛擬機。

服務復制、注冊表和發現。

主動的監控和警報。

鑒于滿足這些要求的可能會是一項重大的投資，且不會立即帶來投資回報，故而使用微服務并非對于每個團隊或項目都是具有成本效益餓。評估整體式的方法可確保應用程序按照實際的設計原則構建，并且域邊界被正確定義，而如果需要可擴展性的話，則逐漸過渡到微服務架構。例如，即使是一個基本的購物車應用程序也應該包含如下方面：

關注點分離。

使用良好定義的應用程序接口(API)來實現高內聚和低耦合。

遵循“迪米特法則(Law of Demeter)”又叫作最少知道原則(Least Knowledge Principle)，實現獨立的接口、API和部署。

分組相關對象的域驅動設計。

一旦需要調整已經根據軟件架構原理構建的整體單片應用程序的規模，則可以將其重構為微服務。最有效的重構方法包括以下步驟：

1、在應用程序的域中確定業務邊界和語義差異，并開始將每個域分解成其自己的微服務。

2、查找經歷過最多更改請求的組件，例如與價格計算或監管更改相關聯的業務規則更新;或經常修補以解決安全問題的漏洞。

3、定義了基于域的基本的微服務后，改進用于讓服務進行交互的API。 使用聚合器、代理、鏈接、分支、事件驅動和其他設計模式編寫這些API。

技術過硬的團隊

企業組織借助微服務實現的成功是緣于其組織架構，而不是其技術。故而具有相應組織架構，跨職能和自主權的靈活的團隊才是關鍵。

打造有效的、技術熟練過硬的團隊需要圍繞功能而不是架構重新調整企業員工隊伍。例如，亞馬遜內部有著非常知名的“兩個披薩團隊”的組織理論,指的是團隊的8至10人數正好相當于可以吃掉2個披薩的人數。由這樣人數的團隊來負責創建和維護他們的服務。而根據康威定律(Conway’s Law)，企業組織只能產生出模仿組織結構的設計。例如，將團隊進行分組，包括了開發團隊、運營團隊、質量保證團隊和安全保護團隊會對靈活性和延遲性方面帶來限制。

在轉換到微服務之前，建立一套DevOps實踐方案可以減輕或阻止這些問題，并通過提前確定通信策略來避免創建失敗的SOA，而不僅僅只是有效的微服務架構。

有效的管理工具

除了精心設計的軟件和一只高效，有組織的團隊，實現高度可擴展的架構還需要借助相應的工具來幫助您企業管理其他服務和應用程序組件，這其中包括：

服務注冊和發現工具，如Kubernetes。

標準化的封裝，用于容器集裝箱化應用程序(如Docker)和用于復制大規模集裝箱的業務流程工具(如Kubernetes)。紅帽公司的OpenShift就包括這兩種經過驗證的開源技術。

CI環境創建工具，如Jenkins或適用于Docker和Kubernetes的Shippable。

依賴性的解析工具，如Nexus。

故障轉移和彈性工具，包括Hystrix和Ribbon等庫。

服務監控、警報和事件提醒工具，如ELK(ElasticSearch、LogStash和Kibana)堆棧。

數據管理

企業轉向微服務的另一項重要的考慮因素便是數據管理。與SOA不同，微服務不共享數據。相反，每款微服務都有一個單獨的物理數據存儲和多存儲持久性，可以讓各種數據庫引擎在每款微服務下運行。因此，可以在每項服務的基礎上選擇數據存儲，而不是將所有數據存儲在一家企業的關系數據庫管理系統(RDBMS)中。

然而，維護企業數據庫的多個副本很可能會增加授權許可的成本和復雜性。此外，數據存儲可能需要保持一致性。通用提取、轉換和加載(ETL)或數據虛擬化工具可以幫助實現數據歸一化，事件采集是一種眾所周知的設計模式，可幫助一致化數據存儲以適應對于變更的追溯。

結論

微服務體系架構可為企業組織機構提供諸多方面的優勢，從不同應用程序組件的獨立可擴展性到更快、更輕松的軟件開發和維護。但是，微服務并非總是有益于每一個團隊或項目，并且可能會在無法帶來立竿見影的投資回報效果的情況下產生重大的投資。過渡到微服務應該是一個循序漸進的過程，遵循從只重構部分現有的應用程序開始逐步到非完全性的過渡的方法也可以為企業組織帶來好處。為了實現微服務的成功，企業組織必須首先根據現有的平臺標準構建精心設計的應用程序，然后根據需要將應用程序重構成微服務集，以滿足企業的業務需求。通過安排合適的人員、流程和工具，微服務可以提供更快的開發和部署，更容易的維護，改進的可擴展性，并免于長期的技術鎖定承諾。