微服務與服務團隊在Amazon的發展

在早先舉辦的 I Love APIs 2015大會 上的一場演講中， Chris Munns 講述了 Amazon如何創建企業級的微服務架構的話題 。微服務模式改變了我們創建應用的方式，而要成功地創建與運行這些微服務，團隊的結構將起到至關重要的作用。

Munns是Amazon的DevOps部門的業務開發經理，他在演講中引用了維基百科上 微服務的定義 ，但同時也列舉了微服務的4條使用上的限制：

• 單一目的。
• 僅通過API進行連接。
• 通過HTTPS協議進行連接。
• 微服務之間大體以 黑盒 的方式展現。

Munns將微服務與SOA進行了比較，列舉了以下這些差異點。

描述團隊的規模有一個著名的術語，即 剛好能吃完兩只披薩的團隊 。在Amazon，這樣的團隊被稱為服務團隊，他們對于創建過程具有完全的自主權，包括產品的計劃、開發工作、運維以及客戶支持。他們具備完全的自主權及責任性，同時也負責每日的運維和維護工作。換句話說， 誰創建的服務，就由誰負責運行 。這意味著質量保證（QA）人員以及運維人員都隸屬于服務團隊之中。但Munns也提到，承擔這一角色的部分員工也有可能由整個組織共享。

對于團隊來說，這樣的文化意味著很高的自由度，但這些團隊將通過以下途徑得到授權并保證實施的高標準：

• 全面的培訓。
• 由具有20年以上開發經驗的員工全面定義各種模式與實踐。
• 在業務與技術兩方面定期進行衡量指標審查。
• 由內部的專家分享關于新工具、服務與技術的知識。

Munn對于小型團隊與微服務在Amazon的發展進行了深入的觀察，以了解其重點所在。對于其他打算按照相同方式發展的組織，Munn提出了一些建議：

• 文化 —— 這里要強調一點，自主權與責任是不可分離的，規模越大的團隊，其運作速度相對于小型團隊將有所下降。團隊要堅持卓越產品的標準，但并非堅守做事的方式一成不變。
• 實踐 —— Munn提到了 持續集成 （CI）與 持續交付 （CD），以及簡化運維任務的重要性。
• 工具 —— 這些工具將用于之前所提到的實踐、基礎設施的管理、指標的設立和監控，以及交流和協作。

Munns最后強調了為服務和客戶建立起一種模式的重要性，這將使組織避免重復發明一些相同的基礎部件，將精力浪費在通信、授權、防止濫用和服務發現等任務上。他還闡述了構建、托管、服務的指標對于觀察基礎設施是否按預期運行、SLA是否得到滿足等問題的重要性。

查看英文原文： Microservices and Teams at Amazon