目前，一些大型企業都在AWS的基礎之上部署微服務架構。這一舉措能夠為企業帶來什么樣的好處呢?
微服務是一個新興的軟件架構，就是把一個大型的單個應用程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工作變得更為簡便，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。
對于大型應用程序來說，增加更多的用戶則意味著提供更大型的彈性計算云(EC2)實例規模，即便只是其中的一些功能擴大了規模亦是如此。其最終結果就是企業用戶只需為支持超過微服務的那部分需求的EC2實例支付費用。一些大型企業(如Netflix和Nike等)都在亞馬遜Web服務(AWS)的基礎之上部署了一個微服務架構，從而提高靈活性和以較低的價格來實現應用程序的擴展。Netflix橫跨其30個工程團隊設計部署了500多個微服務。
在容器和代碼之間進行選擇
微服務架構是把應用程序作為獨立可部署服務組合的一個設計方法。雖然對于這一概念還沒有確切的定義，但是這些架構往往是圍繞業務能力、自動化部署以及去中心化管理來組織設計的。
很多企業都正在使用容器技術，例如基于亞馬遜EC2容器技術的Docker，就讓在EC2實例的托管集群上運行應用程序成為可能。這樣做就降低了對安裝、運行和擴展集群管理基礎設施的要求，而這正是部署單個微服務組件所需要的。但是并不需要為實施微服務而設計容器。
諸如AWS Lamba這樣的新服務讓部署一個微服務架構且無需容器或虛擬機成為了可能。Lambda運行代碼響應事件和管理計算資源，從而讓建立響應事件或流量的微服務集合變得更為簡便。開發人員可以在Lambda上在諸如網站點擊這類毫秒級事件內啟動新服務;計費增量以100毫秒計。
簡化至微服務架構的轉移
企業的架構師們有大量的最佳實踐可以遵循以便最好地實現至微服務的轉移，具體包括正確選擇存儲設施、重新思考傳統IT豎井式系統、創建微服務組件之間的邊界，等等。
為每一個服務選擇最佳數據存儲。微服務架構的優點之一就是單個微服務都是松散耦合的。這樣就能夠讓開發人員選擇最適合某一特定微服務的開發語言和數據存儲，而不是對所有的組件都使用一個數據庫。
使用微服務團隊取代“豎井”。對于一個微服務架構，軟件開發團隊必須保持密切協作和可擴展的態勢。Conway的Law表示，一個軟件系統的接口結構往往反映了開發這一軟件系統的組織的體系結構。為了切換至微服務架構，企業需要組織員工成為有組織的生產團隊并使用開發運營方法。
傳統軟件團隊的組織架構條塊分割，形成了涇渭分明的開發、質保以及生產小組。“你需要一個小型團隊來負責它的微服務——從概念形成、概要設計、詳細編碼、組織測試到實際部署——然后(據推測)就是解bug和升級更新，一家應用程序交付平臺供應商Nginx的產品負責人Owen Garret說。
像對待網絡應用程序一樣看待微服務。必須在微服務組件之間建立強邊界。像對待網絡應用程序一樣看待微服務意味著獨立開發團隊不需要對不同微服務的內部工作原理有一個透徹的理解。反之，微服務需要一個可執行相關功能的API。
“你不需要透露你的微服務的任何內部信息，”Garrett補充道。“另一個微服務的開發團隊完全不需要了解微服務的表達方式或者內部數據是如何對其進行請求的。”只要相關API與其他微服務的關系不被打破，那么這個方法就可以讓開發人員按需求修改微服務。
使用聲明合同。程序使用服務合同的聲明特性，而不是執行如何使用其它服務的程序。使用一個抽象方法來運行需求是更簡便的;一組解釋性的步驟將讓程序變得更為靜態。這意味著開發人員可以通過策略實施應用程序并向基礎設施發送指令。
例如，開發人員可以不對EC2語義進行編碼，他們可以使用策略把數據移至AWS產品。可以把聲明納入到容納微服務的容器中，或者把聲明嵌入到被用于與AWS產品進行通訊的Lamba代碼中。
使用OODA循環。因為不同的團隊會開發不同的微服務，所以企業必須確保軟件開發團隊都有著一個共同的工作目標。這樣，使用Netflix的Observe、Orient、Decide、Act(OODA)循環將會有很大幫助。
在一個OODA循環中，觀察(Observe)涉及檢查代碼庫的當前狀態以尋求進行創新的機會;定向(Orient)表示分析指標以了解已觀察到的現象;決定(Decide)則是制定和執行項目計劃的過程;而行動(act)是測試解決方案并將其投入生產的過程。
京公網安備 11010502049343號