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