給CxO的微服務指南｜洞見
1.未來已經在這里，它只是分布不均。—— 威廉·吉布森
數字時代就在我們身邊。將軟件開發視為高成本開銷而不是競爭力的企業將會舉步維艱。為了參與并在這個數字世界中繁榮興旺，企業必須學會適應我們這個時代的不確定性—更快地將新產品推向市場，快速而有效地改進當前的產品，并為客戶提供有意義的數字體驗。
為了實現這些目標，企業需要將敏捷性/適應性集成到三個領域：人、流程和技術。
人們需要適應試驗和改變。以“迭代”的形式推進這一過程，并加強學習。技術，包括技術架構，需要支持快速地交付產品與服務。
技術的敏捷性不能被忽視——敏捷的團隊和流程并不能彌補笨重的技術所帶來的缺陷。
但作為一個高級管理人員，在這樣一個充滿了新技術的世界，你應該將注意力投注在哪里呢?
這個問題的答案被那些不停地討論著看似神秘話題的技術人員們所掩蓋。哪些神秘的話題需要得到管理層的注意呢?其中最重要的話題之一是微服務。原因如下所述：
微服務影響人、流程和技術：包括團隊組織結構，流程和實踐(如DevOps)，以及重新調整架構以適應我們要解決的問題，而并非純技術層面。微服務促進了每個領域的適應性。它值得管理層花時間去了解其潛在的貢獻。
技術敏捷度
微服務架構風格的特性是由一組極小的服務組成，它們彼此獨立且單獨部署。微服務由Netflix這樣的公司推廣開來。每個服務包含一個離散的業務功能，它在技術上與其他服務相隔離，產生了類似樂高積木的效果：開發人員可以將服務切換為一個新的服務，而無需破壞其他服務。就像巨型的樂高模型可以由75,000塊樂高組成，大型的數字應用程序也可以由這些受樂高思想啟發的服務所構建。
這種架構有一些明顯的好處。
首先，每個服務與其他服務高度解耦，這意味著它們是自包含的。因此，一個服務中的技術更改(例如數據結構更改)不會影響另一個服務。服務仍然可以通過消息傳遞進行通信，但是任何一個服務都不允許修改另一個服務的實現細節。
第二，因為開發人員不需要共享基礎設施，他們可以選用適合于該問題復雜度的技術棧來實現每一個服務。考慮到當今技術棧的復雜性，在同一應用程序中，使用簡單工具處理簡單問題和使用復雜工具處理復雜問題的能力使開發團隊在增加了靈活性的同時也降低了成本。***重視能將復雜問題簡化的技術專家。
第三，每個服務封裝了業務功能，它更容易促成圍繞特定問題域的團隊，而不是通過作業功能分割的團隊。例如，服務團隊通常包括開發人員、業務分析師、DBA、運維人員和QA—即構建和部署服務所需的一切角色。這樣一來便降低了協調成本。
“從功能性組織結構向產品或服務結構轉變”是敏捷企業轉型的一個日益增長的趨勢。而微服務架構支持了這種趨勢的變化。
***，因為每個服務是相互隔離的，所以以服務組成的架構既快速又靈活。同時因為服務的業務范圍很小，對服務的更改可以快速地發生，這為開發人員提供了新的高級功能。一旦架構師設計了一個小型獨立服務的系統，其中應用程序由部署的多個服務之間的消息傳遞組成，多變量測試等操作就變得容易了。
(圖片來自：https://dt-cdn.net/)
例如，企業可能對他們網站的未來發展方向并不確定。因此他們設計了具有相似性但功能不同的兩種服務，并向不同的用戶組部署不同的版本，以獲取結果從而推動未來的發展。像Facebook這樣的公司也是通過使用這種類型的A / B測試進行試驗來分析他們的用戶。
標準化一直是IT組織降低成本的方式之一。不幸的是，它也降低了靈活性—標準化越多，靈活性越少。通過采納微服務架構，架構師和開發人員可以使用更加多樣化且能夠緊密反映問題復雜度的技術棧來設計應用程序。
微服務架構風格與許多企業部署軟件和分配IT資源的方式相反。許多架構風格的主要目標之一是有效地利用共享資源(操作系統、數據庫服務器、應用程序服務器等)。由于資源的成本影響了底線，因此這些公司建立了軟件架構以***化共享資源。
然而，共享資源有一個缺點。無論開發人員如何有效地構建與這些服務器的隔離，都會出現對這些資源的競爭。有時組件由于依賴管理而互相干擾，有時由于兩個組件爭用某些資源(例如CPU)而產生問題。這就不可避免地會導致共享組件以并不期望的方式進行交互。
容器和解耦
在軟件交付中，有兩個關鍵的技術“環境”：開發人員工作的開發環境，以及IT運維人員管轄范圍的部署環境。傳統情況下，在這兩個環境之間移動代碼充滿了技術錯誤，冗長的時間延遲以及組織層面的溝通不暢。
幾年前，一些有趣的事情發生了：Linux對于大多數企業足夠友好，Linux的變體在商業上免費—但是這不足以影響技術架構。
接下來，開源的創新與敏捷開發技術的結合鼓勵了開發人員創建各種工具，將許多繁瑣的運維手工操作自動化。這被許多人稱為DevOps革命。
這場革命使得開發團隊和IT運維人員通過使用Puppet、Chef和Docker等高級工具更加緊密地聯系在一起。意外地，Linux的變體允許免費操作，開發人員可以在不受干擾的情況下將其組件部署到一個原始的操作系統。一整個可能的錯誤類別就突然消失了，因為組件之間能夠相互解耦。
如果開發人員可以構建他們自己的現實環境，他們必須減少與運維部門的協調，也就減少了組織間的摩擦。用程序啟動類生產環境的能力消除了測試、集成、共享環境下的資源競爭、以及一系列其他問題。
21世紀的架構敏捷度
在治理方面，微服務架構風格有其他的好處。傳統的做法是，企業架構師定義了組織的共享技術棧，以***化項目間的資源使用，同時***程度地減少支撐成本。例如，一個大型企業可能將Java和Oracle標準化以作為其主要開發平臺。如果每個人都使用Oracle，那么該企業的一切都可以存儲在一個工業強度的數據庫中。
規范化治理有一個缺點—通常，為了標準化的某一目的，團隊必須使用并不太理想的工具。與此同時，還有一個潛在的更微妙的缺點。例如，考慮一個已經選擇在特定消息隊列上標準化的大型企業。在評估需要此共享基礎設施的所有項目時，企業架構師會找出最復雜的場景，并選擇一個適合這種復雜度的工具來處理它們。
然而，許多項目并不具備這個最復雜的場景。但因為每個項目必須共享相同的基礎設施，所以每個團隊都得承擔其他團隊的***復雜度。這種情況也發生在數據庫層。許多項目只需要幾個記錄的簡單數據存儲，并不需要復雜的查詢功能，但最終都使用了具有工業強度的數據庫服務器，只因為這個企業的標準如此。
容器化技術解決了這個問題，因為它遠離了共享基礎設施—每個項目都部署在自己原始的、容器化的環境中。因為不存在共享的動力去選擇工具，所以每個項目刻意選擇更適合自己的工具。
當然，如果企業架構師允許每個項目選擇自己的技術棧，那么會存在一些嚴重的缺點。我們經常看到一個稱之為“Goldilocks治理”(企業架構師選擇幾個技術棧—簡單、中等和復雜，并根據規模分配新項目)的實踐，它適用于高度解耦的環境。這些知識是可遷移的，該公司仍然可以從中受益，但是卻可以遠離那些由于疏忽大意而將問題過于復雜化的行為。
為什么我們會談到這兒?
Eric Evans的《領域驅動設計》一書對微服務架構發展產生了巨大的影響。它介紹了一種將大問題空間分解為領域或重要實體(如客戶和訂單)及其關系(客戶下訂單)和行為的技術。領域定義的一部分是有關邊界上下文的概念：每個領域形成一個圍繞實現細節的封裝層。
例如，如果分析人員識別了一個Customer領域，那么它存在于自己的邊界上下文中。在Customer的上下文中，開發人員知道所有的實現細節：類結構，數據庫模式等。
但是，其他邊界上下文(如Orders)不能看到這些實現細節。雖然領域可以為了協調的目的互相發送消息，但是任何一個領域都不能穿透另一個領域的邊界上下文。因此，在一個邊界上下文中的開發人員可以自由地更改實現，而不必擔心破壞其他領域。
微服務中的容器是領域驅動設計(DDD)中邊界上下文的物理表現：每個容器代表了一層封裝，以防止實現細節干擾系統的其他部分。邊界上下文提供的隔離展示了結構化軟件架構的不同方式。
在過去，設計架構主要圍繞技術架構：架構模式、庫、框架等。例如，分層架構在許多組織中是很常見的：
圖1：傳統的分層架構
在圖1中，架構師沿技術層進行分離，使之在需要時可以很容易地替換一整層的內容。例如，如果開發人員需要更改持久機制，所有相關代碼都會出現在持久層中。
那么開發人員多久更換一次整個持久層呢?幾乎從不。但你的團隊多長時間基于像Customer這樣的概念工作呢?每天!
在圖1分層架構中，Customer處于哪一層呢?其中部分在表示層、業務層、持久層等等。因此，項目架構上通用單元的變化在分層架構中并沒有得到很好的支持，原因是通用的變更影響到了每一層。
如果不同層代表了開發團隊的不同部分，其影響會更嚴重。例如，對Customer的更改可能涉及到用戶界面、業務邏輯、持久層和其他特性。如果你的組織由開發人員、DBA、用戶界面設計師和運維人員組成，而他們在相互隔離的HR部門下，那么進行常見更改的協調成本是巨大的。
微服務強調解耦和容器化，翻轉了圖1中的傳統做法，使領域成為架構的主要元素，如圖2所示。
圖2：以領域為中心的架構
在圖2中，分層結構仍然存在，但是其耦合邊界是領域的邊界，它將技術架構歸入實現細節，并用領域對其進行封裝。以技術為中心的組織單元中，員工與員工彼此隔離，要想在這樣的組織中構建以領域為中心的架構是很難的。
許多技術人員在構建數字化企業中會遇到這樣的問題：想要支持如移動應用等新舉措，卻被那些需要拆分的遺留系統所拖累。如今，這些企業越來越多地引入微服務作為這種拆分過程的關鍵戰略。
Greenfield項目得益于DDD實踐。通過DDD理解了他們的問題領域以及重要組件之間的接口所在。對于現有項目，更加模塊化的系統會促使開發者解開事務性的泥球，并且可以在那些屬于一起的組件和偶然耦合的組件之間做更清楚地區分。
團隊
你還將遇到微服務對團隊影響：一個架構風格是如何推動開發團隊重組的。
1968年，梅爾文·康威對軟件開發做了一個很有預見性的觀察，被稱為康威定律：設計系統的組織，其產生的設計等價于這些組織間的溝通結構。
康威定律對軟件開發的意義是什么呢?你的設計反映了你的團隊結構。企業常見的團隊結構是由人力資源部門推動的，他們將職能類似的技術專家組織在一起。雖然這是一種符合邏輯的排序算法，但這種結構在設計自包含服務時效果不佳。
如我們認為的康威逆定律，現在許多公司在圍繞業務領域組織跨職能團隊，而不是圍繞技術分層構建。例如，一個Customer服務可能包括一個業務分析師、開發人員、QA、UX、DBA和運維人員。
團隊會在準備好之后再部署服務，而不是先構建一些東西傳遞到運維人員，使之包含在下一個巨大的發布中。許多選擇微服務的公司使用持續部署，以盡快將變更投入生產環境中。
總結
企業高管可能會認為“微服務”是***流行詞而不予考慮，但那些了解這種架構影響的人可以獲得實實在在的好處。微服務可以提高交付速度，增強靈活性，并提高效率。他們將工作進行重組，并與業務問題域保持一致，而不是技術域;從一組獨立，更易于開發和維護的服務中創建業務應用程序;更好地匹配技術解決方案與業務問題的復雜程度;構建可以幫助重組現有遺留系統以及創建能夠快速響應不斷變化的業務條件的新產品和服務的自適應架構。
威廉·吉布森是正確的—許多公司已經將IT競爭力看作魯棒性一個新的度量。對于這些企業來說，未來已經在這里了。其他還沒有意識到這一點的公司可能會發現他們的未來已經受到了影響。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
