文/JimHighsmith&NealFord　譯者/禚嫻靜

這是技術雷達系列文章的第四篇吃警。在這一系列的文章中牧嫉，技術雷達的作者們向企業(yè)領導者分享了他們對于那些推動業(yè)務差異化的技術問題和解決方案的洞見和經(jīng)驗。ThoughtWorks技術雷達由ThoughtWorks全球技術專家咨詢委員會創(chuàng)建乎澄，它包含了對軟件開發(fā)和業(yè)務戰(zhàn)略有顯著影響的技術趨勢組合囚灼，2016年是技術雷達發(fā)布的第七年特铝。

未來已經(jīng)在這里，它只是分布不均棍郎。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?—威廉·吉布森

數(shù)字時代就在我們身邊其障。將軟件開發(fā)視為高成本開銷而不是競爭力的企業(yè)將會舉步維艱。為了參與并在這個數(shù)字世界中繁榮興旺涂佃，企業(yè)必須學會適應我們這個時代的不確定性—更快地將新產(chǎn)品推向市場励翼，快速而有效地改進當前的產(chǎn)品，并為客戶提供有意義的數(shù)字體驗辜荠。

為了實現(xiàn)這些目標汽抚，企業(yè)需要將敏捷性/適應性集成到三個領域：人、流程和技術侨拦。

人們需要適應試驗和改變殊橙。以“迭代”的形式推進這一過程，并加強學習狱从。技術膨蛮，包括技術架構，需要支持快速地交付產(chǎn)品與服務季研。

技術的敏捷性不能被忽視——敏捷的團隊和流程并不能彌補笨重的技術所帶來的缺陷敞葛。

但作為一個高級管理人員，在這樣一個充滿了新技術的世界与涡，你應該將注意力投注在哪里呢惹谐？

這個問題的答案被那些不停地討論著看似神秘話題的技術人員們所掩蓋持偏。哪些神秘的話題需要得到管理層的注意呢？其中最重要的話題之一是微服務氨肌。原因如下所述：

微服務影響人鸿秆、流程和技術：包括團隊組織結構，流程和實踐（如DevOps）怎囚，以及重新調整架構以適應我們要解決的問題卿叽，而并非純技術層面。微服務促進了每個領域的適應性恳守。它值得管理層花時間去了解其潛在的貢獻考婴。

技術敏捷度

微服務架構風格的特性是由一組極小的服務組成，它們彼此獨立且單獨部署催烘。微服務由Netflix這樣的公司推廣開來沥阱。每個服務包含一個離散的業(yè)務功能，它在技術上與其他服務相隔離伊群，產(chǎn)生了類似樂高積木的效果：開發(fā)人員可以將服務切換為一個新的服務考杉，而無需破壞其他服務。就像巨型的樂高模型可以由75,000塊樂高組成在岂，大型的數(shù)字應用程序也可以由這些受樂高思想啟發(fā)的服務所構建奔则。

這種架構有一些明顯的好處。首先蔽午，每個服務與其他服務高度解耦易茬，這意味著它們是自包含的。因此及老，一個服務中的技術更改（例如數(shù)據(jù)結構更改）不會影響另一個服務抽莱。服務仍然可以通過消息傳遞進行通信，但是任何一個服務都不允許修改另一個服務的實現(xiàn)細節(jié)骄恶。

第二食铐，因為開發(fā)人員不需要共享基礎設施，他們可以選用適合于該問題復雜度的技術棧來實現(xiàn)每一個服務僧鲁∨吧耄考慮到當今技術棧的復雜性，在同一應用程序中寞秃，使用簡單工具處理簡單問題和使用復雜工具處理復雜問題的能力使開發(fā)團隊在增加了靈活性的同時也降低了成本斟叼。領導者重視能將復雜問題簡化的技術專家。

第三春寿，每個服務封裝了業(yè)務功能朗涩，它更容易促成圍繞特定問題域的團隊，而不是通過作業(yè)功能分割的團隊绑改。例如谢床，服務團隊通常包括開發(fā)人員兄一、業(yè)務分析師、DBA识腿、運維人員和QA—即構建和部署服務所需的一切角色出革。這樣一來便降低了協(xié)調成本。

“從功能性組織結構向產(chǎn)品或服務結構轉變”是敏捷企業(yè)轉型的一個日益增長的趨勢渡讼。而微服務架構支持了這種趨勢的變化蹋盆。

最后，因為每個服務是相互隔離的硝全，所以以服務組成的架構既快速又靈活。同時因為服務的業(yè)務范圍很小楞抡，對服務的更改可以快速地發(fā)生伟众，這為開發(fā)人員提供了新的高級功能。一旦架構師設計了一個小型獨立服務的系統(tǒng)召廷，其中應用程序由部署的多個服務之間的消息傳遞組成凳厢，多變量測試等操作就變得容易了。

例如竞慢，企業(yè)可能對他們網(wǎng)站的未來發(fā)展方向并不確定先紫。因此他們設計了具有相似性但功能不同的兩種服務，并向不同的用戶組部署不同的版本筹煮，以獲取結果從而推動未來的發(fā)展遮精。像Facebook這樣的公司也是通過使用這種類型的A/B測試進行試驗來分析他們的用戶。

標準化一直是IT組織降低成本的方式之一败潦。不幸的是本冲，它也降低了靈活性—標準化越多，靈活性越少劫扒。通過采納微服務架構檬洞，架構師和開發(fā)人員可以使用更加多樣化且能夠緊密反映問題復雜度的技術棧來設計應用程序。

微服務架構風格與許多企業(yè)部署軟件和分配IT資源的方式相反沟饥。許多架構風格的主要目標之一是有效地利用共享資源（操作系統(tǒng)添怔、數(shù)據(jù)庫服務器、應用程序服務器等）贤旷。由于資源的成本影響了底線广料，因此這些公司建立了軟件架構以最大化共享資源。

然而遮晚，共享資源有一個缺點性昭。無論開發(fā)人員如何有效地構建與這些服務器的隔離，都會出現(xiàn)對這些資源的競爭县遣。有時組件由于依賴管理而互相干擾糜颠，有時由于兩個組件爭用某些資源（例如CPU）而產(chǎn)生問題汹族。這就不可避免地會導致共享組件以并不期望的方式進行交互。

容器和解耦

在軟件交付中其兴，有兩個關鍵的技術“環(huán)境”：開發(fā)人員工作的開發(fā)環(huán)境顶瞒，以及IT運維人員管轄范圍的部署環(huán)境。傳統(tǒng)情況下元旬，在這兩個環(huán)境之間移動代碼充滿了技術錯誤榴徐，冗長的時間延遲以及組織層面的溝通不暢。

幾年前匀归，一些有趣的事情發(fā)生了：Linux對于大多數(shù)企業(yè)足夠友好坑资，Linux的變體在商業(yè)上免費—但是這不足以影響技術架構。

接下來穆端，開源的創(chuàng)新與敏捷開發(fā)技術的結合鼓勵了開發(fā)人員創(chuàng)建各種工具袱贮，將許多繁瑣的運維手工操作自動化。這被許多人稱為DevOps革命体啰。

這場革命使得開發(fā)團隊和IT運維人員通過使用Puppet攒巍、Chef和Docker等高級工具更加緊密地聯(lián)系在一起。意外地荒勇，Linux的變體允許免費操作柒莉，開發(fā)人員可以在不受干擾的情況下將其組件部署到一個原始的操作系統(tǒng)。一整個可能的錯誤類別就突然消失了沽翔，因為組件之間能夠相互解耦兢孝。

如果開發(fā)人員可以構建他們自己的現(xiàn)實環(huán)境，他們必須減少與運維部門的協(xié)調搀擂，也就減少了組織間的摩擦西潘。用程序啟動類生產(chǎn)環(huán)境的能力消除了測試、集成哨颂、共享環(huán)境下的資源競爭喷市、以及一系列其他問題。

21世紀的架構敏捷度

在治理方面威恼，微服務架構風格有其他的好處品姓。傳統(tǒng)的做法是，企業(yè)架構師定義了組織的共享技術棧箫措，以最大化項目間的資源使用腹备，同時最大程度地減少支撐成本。例如斤蔓，一個大型企業(yè)可能將Java和Oracle標準化以作為其主要開發(fā)平臺植酥。如果每個人都使用Oracle，那么該企業(yè)的一切都可以存儲在一個工業(yè)強度的數(shù)據(jù)庫中。

規(guī)范化治理有一個缺點—通常友驮，為了標準化標準化的某一目的漂羊，團隊必須使用并不太理想的工具。與此同時卸留，還有一個潛在的更微妙的缺點走越。例如，考慮一個已經(jīng)選擇在特定消息隊列上標準化的大型企業(yè)耻瑟。在評估需要此共享基礎設施的所有項目時旨指，企業(yè)架構師會找出最復雜的場景，并選擇一個適合這種復雜度的工具來處理它們喳整。

然而谆构，許多項目并不具備這個最復雜的場景。但因為每個項目必須共享相同的基礎設施框都，所以每個團隊都得承擔其他團隊的最大復雜度低淡。這種情況也發(fā)生在數(shù)據(jù)庫層。許多項目只需要幾個記錄的簡單數(shù)據(jù)存儲瞬项，并不需要復雜的查詢功能，但最終都使用了具有工業(yè)強度的數(shù)據(jù)庫服務器何荚，只因為這個企業(yè)的標準如此囱淋。

容器化技術解決了這個問題，因為它遠離了共享基礎設施—每個項目都部署在自己原始的餐塘、容器化的環(huán)境中妥衣。因為不存在共享的動力去選擇工具，所以每個項目刻意選擇更適合自己的自己的工具戒傻。

當然税手，如果企業(yè)架構師允許每個項目選擇自己的技術棧，那么會存在一些嚴重的缺點需纳。我們經(jīng)陈梗看到一個稱之為““Goldilocks治理”（企業(yè)架構師選擇幾個技術棧—簡單不翩、中等和復雜兵扬，并根據(jù)規(guī)模分配新項目）的實踐，它適用于高度解耦的環(huán)境口蝠。這些知識是可遷移的器钟，該公司仍然可以從中受益，但是卻可以遠離那些由于疏忽大意而將問題過于復雜化的行為妙蔗。

為什么我們會談到這兒傲霸？

Eric Evans的《領域驅動設計》一書對微服務架構發(fā)展產(chǎn)生了巨大的影響。它介紹了一種將大問題空間分解為領域或重要實體（如客戶和訂單）及其關系（客戶下訂單）和行為的技術。領域定義的一部分是有關邊界上下文的概念：每個領域形成一個圍繞實現(xiàn)細節(jié)的封裝層昙啄。

例如穆役，如果分析人員識別了一個Customer領域，那么它存在于自己的邊界上下文中跟衅。在Customer的上下文中孵睬，開發(fā)人員知道所有的實現(xiàn)細節(jié)：類結構，數(shù)據(jù)庫模式等伶跷。

但是砍聊，其他邊界上下文（如Orders）不能看到這些實現(xiàn)細節(jié)。雖然領域可以為了協(xié)調的目的互相發(fā)送消息树姨，但是任何一個領域都不能穿透另一個領域的邊界上下文经宏。因此，在一個邊界上下文中的開發(fā)人員可以自由地更改實現(xiàn)雇初，而不必擔心破壞其他領域拢肆。

微服務中的容器是領域驅動設計（DDD）中邊界上下文的物理表現(xiàn)：每個容器代表了一層封裝，以防止實現(xiàn)細節(jié)干擾系統(tǒng)的其他部分靖诗。邊界上下文提供的隔離展示了結構化軟件架構的不同方式郭怪。

在過去，設計架構主要圍繞技術架構：架構架構模式刊橘、庫鄙才、框架等。例如促绵，分層架構在許多組織中是很常見的：

傳統(tǒng)的分層架構

在圖1中攒庵，架構師沿技術層進行分離，使之在需要時可以很容易地替換一整層的內容败晴。例如浓冒，如果開發(fā)人員需要更改持久機制，所有相關代碼都會出現(xiàn)在持久層中尖坤。

那么開發(fā)人員多久更換一次整個持久層呢稳懒？幾乎從不。但你的團隊多長時間基于像Customer這樣的概念工作呢慢味？每天僚祷！

在圖1分層架構中，Customer處于哪一層呢贮缕？其中部分在表示層辙谜、業(yè)務層、持久層等等感昼。因此装哆，項目架構上通用單元的變化在分層架構中并沒有得到很好的支持，原因是通用的變更影響到了每一層。

如果不同層代表了開發(fā)團隊的不同部分蜕琴，其影響會更嚴重萍桌。例如，對Customer的更改可能涉及到用戶界面凌简、業(yè)務邏輯上炎、持久層和其他特性。如果你的組織由開發(fā)人員雏搂、DBA藕施、用戶界面設計師和運維人員組成，而他們在相互隔離的HR部門下凸郑，那么進行常見更改的協(xié)調成本是巨大的裳食。

微服務強調解耦和容器化，翻轉了圖1中的傳統(tǒng)做法芙沥，使領域成為架構的主要元素诲祸，如圖2所示。

在圖2中而昨，分層結構仍然存在救氯，但是其耦合邊界是領域的邊界，它將技術架構歸入實現(xiàn)細節(jié)歌憨，并用領域對其進行封裝径密。以技術為中心的組織單元中，員工與員工彼此隔離躺孝，要想在這樣的組織中構建以領域為中心的架構是很難的。

許多技術人員在構建數(shù)字化企業(yè)中會遇到這樣的問題：想要支持如移動應用等新舉措底桂，卻被那些需要拆分的遺留系統(tǒng)所拖累植袍。如今，這些企業(yè)越來越多地引入微服務作為這種拆分過程的關鍵戰(zhàn)略籽懦。

Greenfield項目得益于DDD實踐于个。通過DDD理解了他們的問題領域以及重要組件之間的接口所在。對于現(xiàn)有項目暮顺，更加模塊化的系統(tǒng)會促使開發(fā)者解開事務性的泥球厅篓，并且可以在那些屬于一起的組件和偶然耦合的組件之間做更清楚地區(qū)分。

團隊

你還將遇到微服務對團隊影響：一個架構風格是如何推動開發(fā)團隊重組的捶码。

1968年羽氮，梅爾文·康威對軟件開發(fā)做了一個很有預見性的觀察，被稱為康威定律：

設計系統(tǒng)的組織惫恼，其產(chǎn)生的設計等價于這些組織間的溝通結構档押。

康威定律對軟件開發(fā)的意義是什么呢？你的設計反映了你的團隊結構。企業(yè)常見的團隊結構是由人力資源部門推動的令宿，他們將職能類似類似的技術專家組織在一起叼耙。雖然這是一種符合邏輯的排序算法，但這種結構在設計自包含服務時效果不佳粒没。

如我們認為的康威逆定律筛婉，現(xiàn)在許多公司在圍繞業(yè)務領域組織跨職能團隊，而不是圍繞技術分層構建癞松。例如爽撒，一個Customer服務可能包括一個業(yè)務分析師、開發(fā)人員拦惋、QA匆浙、UX、DBA和運維人員厕妖。

團隊會在準備好之后再部署服務首尼，而不是先構建一些東西傳遞到運維人員，使之包含在下一個巨大的發(fā)布中言秸。許多選擇微服務的公司使用持續(xù)部署软能，以盡快將變更投入生產(chǎn)環(huán)境中。

總結

企業(yè)高管可能會認為微服務是最新流行詞而不予考慮举畸，但那些了解這種架構影響的人可以獲得實實在在的好處查排。微服務可以提高交付速度，增強靈活性抄沮，并提高效率跋核。他們將工作進行重組，并與業(yè)務問題域保持一致叛买，而不是技術域砂代；從一組獨立，更易于開發(fā)和維護的服務中創(chuàng)建業(yè)務應用程序率挣；更好地匹配技術解決方案與業(yè)務問題的復雜程度刻伊；構建可以幫助重組現(xiàn)有遺留系統(tǒng)以及創(chuàng)建能夠快速響應不斷變化的業(yè)務條件的新產(chǎn)品和服務的自適應架構。

威廉·吉布森是正確的 — 許多公司已經(jīng)將IT競爭力看作魯棒性一個新的度量椒功。對于這些企業(yè)來說捶箱，未來已經(jīng)在這里了。其他還沒有意識到這一點的公司可能會發(fā)現(xiàn)他們的未來已經(jīng)受到了影響动漾。

原文鏈接：https://www.thoughtworks.com/cn/insights/blog/cxo-guide-microservices