文／Jim Highsmith & Neal Ford 譯者／禚嫻靜

這是技術(shù)雷達(dá)系列文章的第四篇妆偏。在這一系列的文章中刨肃，技術(shù)雷達(dá)的作者們向企業(yè)領(lǐng)導(dǎo)者分享了他們對(duì)于那些推動(dòng)業(yè)務(wù)差異化的技術(shù)問題和解決方案的洞見和經(jīng)驗(yàn)古拴。ThoughtWorks技術(shù)雷達(dá)由ThoughtWorks全球技術(shù)專家咨詢委員會(huì)創(chuàng)建箩帚，它包含了對(duì)軟件開發(fā)和業(yè)務(wù)戰(zhàn)略有顯著影響的技術(shù)趨勢組合真友，2016年是技術(shù)雷達(dá)發(fā)布的第七年。

未來已經(jīng)在這里紧帕，它只是分布不均盔然。—— 威廉·吉布森

數(shù)字時(shí)代就在我們身邊是嗜。將軟件開發(fā)視為高成本開銷而不是競爭力的企業(yè)將會(huì)舉步維艱愈案。為了參與并在這個(gè)數(shù)字世界中繁榮興旺，企業(yè)必須學(xué)會(huì)適應(yīng)我們這個(gè)時(shí)代的不確定性—更快地將新產(chǎn)品推向市場鹅搪，快速而有效地改進(jìn)當(dāng)前的產(chǎn)品站绪，并為客戶提供有意義的數(shù)字體驗(yàn)。

為了實(shí)現(xiàn)這些目標(biāo)丽柿，企業(yè)需要將敏捷性/適應(yīng)性集成到三個(gè)領(lǐng)域：人恢准、流程和技術(shù)。

人們需要適應(yīng)試驗(yàn)和改變甫题。以“迭代”的形式推進(jìn)這一過程馁筐，并加強(qiáng)學(xué)習(xí)。技術(shù)坠非，包括技術(shù)架構(gòu)敏沉，需要支持快速地交付產(chǎn)品與服務(wù)。

技術(shù)的敏捷性不能被忽視——敏捷的團(tuán)隊(duì)和流程并不能彌補(bǔ)笨重的技術(shù)所帶來的缺陷炎码。

但作為一個(gè)高級(jí)管理人員盟迟，在這樣一個(gè)充滿了新技術(shù)的世界，你應(yīng)該將注意力投注在哪里呢潦闲？

這個(gè)問題的答案被那些不停地討論著看似神秘話題的技術(shù)人員們所掩蓋攒菠。哪些神秘的話題需要得到管理層的注意呢？其中最重要的話題之一是微服務(wù)矫钓。原因如下所述：

微服務(wù)影響人要尔、流程和技術(shù)：包括團(tuán)隊(duì)組織結(jié)構(gòu)舍杜，流程和實(shí)踐（如DevOps），以及重新調(diào)整架構(gòu)以適應(yīng)我們要解決的問題赵辕，而并非純技術(shù)層面既绩。微服務(wù)促進(jìn)了每個(gè)領(lǐng)域的適應(yīng)性。它值得管理層花時(shí)間去了解其潛在的貢獻(xiàn)还惠。

技術(shù)敏捷度

微服務(wù)架構(gòu)風(fēng)格的特性是由一組極小的服務(wù)組成饲握，它們彼此獨(dú)立且單獨(dú)部署。微服務(wù)由Netflix這樣的公司推廣開來蚕键。每個(gè)服務(wù)包含一個(gè)離散的業(yè)務(wù)功能救欧，它在技術(shù)上與其他服務(wù)相隔離，產(chǎn)生了類似樂高積木的效果：開發(fā)人員可以將服務(wù)切換為一個(gè)新的服務(wù)锣光，而無需破壞其他服務(wù)笆怠。就像巨型的樂高模型可以由75,000塊樂高組成，大型的數(shù)字應(yīng)用程序也可以由這些受樂高思想啟發(fā)的服務(wù)所構(gòu)建誊爹。

這種架構(gòu)有一些明顯的好處蹬刷。首先，每個(gè)服務(wù)與其他服務(wù)高度解耦频丘，這意味著它們是自包含的办成。因此，一個(gè)服務(wù)中的技術(shù)更改（例如數(shù)據(jù)結(jié)構(gòu)更改）不會(huì)影響另一個(gè)服務(wù)搂漠。服務(wù)仍然可以通過消息傳遞進(jìn)行通信迂卢，但是任何一個(gè)服務(wù)都不允許修改另一個(gè)服務(wù)的實(shí)現(xiàn)細(xì)節(jié)。

第二桐汤，因?yàn)殚_發(fā)人員不需要共享基礎(chǔ)設(shè)施而克，他們可以選用適合于該問題復(fù)雜度的技術(shù)棧來實(shí)現(xiàn)每一個(gè)服務(wù)【疲考慮到當(dāng)今技術(shù)棧的復(fù)雜性拍摇，在同一應(yīng)用程序中，使用簡單工具處理簡單問題和使用復(fù)雜工具處理復(fù)雜問題的能力使開發(fā)團(tuán)隊(duì)在增加了靈活性的同時(shí)也降低了成本馆截。領(lǐng)導(dǎo)者重視能將復(fù)雜問題簡化的技術(shù)專家充活。

第三，每個(gè)服務(wù)封裝了業(yè)務(wù)功能蜡娶，它更容易促成圍繞特定問題域的團(tuán)隊(duì)混卵，而不是通過作業(yè)功能分割的團(tuán)隊(duì)。例如窖张，服務(wù)團(tuán)隊(duì)通常包括開發(fā)人員幕随、業(yè)務(wù)分析師、DBA宿接、運(yùn)維人員和QA—即構(gòu)建和部署服務(wù)所需的一切角色赘淮。這樣一來便降低了協(xié)調(diào)成本辕录。

“從功能性組織結(jié)構(gòu)向產(chǎn)品或服務(wù)結(jié)構(gòu)轉(zhuǎn)變”是敏捷企業(yè)轉(zhuǎn)型的一個(gè)日益增長的趨勢。而微服務(wù)架構(gòu)支持了這種趨勢的變化梢卸。

最后走诞，因?yàn)槊總€(gè)服務(wù)是相互隔離的，所以以服務(wù)組成的架構(gòu)既快速又靈活蛤高。同時(shí)因?yàn)榉?wù)的業(yè)務(wù)范圍很小蚣旱，對(duì)服務(wù)的更改可以快速地發(fā)生，這為開發(fā)人員提供了新的高級(jí)功能戴陡。一旦架構(gòu)師設(shè)計(jì)了一個(gè)小型獨(dú)立服務(wù)的系統(tǒng)塞绿，其中應(yīng)用程序由部署的多個(gè)服務(wù)之間的消息傳遞組成，多變量測試等操作就變得容易了恤批。

例如异吻，企業(yè)可能對(duì)他們網(wǎng)站的未來發(fā)展方向并不確定。因此他們?cè)O(shè)計(jì)了具有相似性但功能不同的兩種服務(wù)开皿，并向不同的用戶組部署不同的版本涧黄，以獲取結(jié)果從而推動(dòng)未來的發(fā)展篮昧。像Facebook這樣的公司也是通過使用這種類型的A / B測試進(jìn)行試驗(yàn)來分析他們的用戶赋荆。

標(biāo)準(zhǔn)化一直是IT組織降低成本的方式之一。不幸的是懊昨，它也降低了靈活性—標(biāo)準(zhǔn)化越多窄潭，靈活性越少。通過采納微服務(wù)架構(gòu)酵颁，架構(gòu)師和開發(fā)人員可以使用更加多樣化且能夠緊密反映問題復(fù)雜度的技術(shù)棧來設(shè)計(jì)應(yīng)用程序嫉你。

微服務(wù)架構(gòu)風(fēng)格與許多企業(yè)部署軟件和分配IT資源的方式相反。許多架構(gòu)風(fēng)格的主要目標(biāo)之一是有效地利用共享資源（操作系統(tǒng)躏惋、數(shù)據(jù)庫服務(wù)器幽污、應(yīng)用程序服務(wù)器等）。由于資源的成本影響了底線簿姨，因此這些公司建立了軟件架構(gòu)以最大化共享資源距误。

然而，共享資源有一個(gè)缺點(diǎn)扁位。無論開發(fā)人員如何有效地構(gòu)建與這些服務(wù)器的隔離准潭，都會(huì)出現(xiàn)對(duì)這些資源的競爭。有時(shí)組件由于依賴管理而互相干擾域仇，有時(shí)由于兩個(gè)組件爭用某些資源（例如CPU）而產(chǎn)生問題刑然。這就不可避免地會(huì)導(dǎo)致共享組件以并不期望的方式進(jìn)行交互。

容器和解耦

在軟件交付中暇务，有兩個(gè)關(guān)鍵的技術(shù)“環(huán)境”：開發(fā)人員工作的開發(fā)環(huán)境泼掠，以及IT運(yùn)維人員管轄范圍的部署環(huán)境怔软。傳統(tǒng)情況下，在這兩個(gè)環(huán)境之間移動(dòng)代碼充滿了技術(shù)錯(cuò)誤择镇，冗長的時(shí)間延遲以及組織層面的溝通不暢爽雄。

幾年前，一些有趣的事情發(fā)生了：Linux對(duì)于大多數(shù)企業(yè)足夠友好沐鼠，Linux的變體在商業(yè)上免費(fèi)—但是這不足以影響技術(shù)架構(gòu)挚瘟。

接下來，開源的創(chuàng)新與敏捷開發(fā)技術(shù)的結(jié)合鼓勵(lì)了開發(fā)人員創(chuàng)建各種工具饲梭，將許多繁瑣的運(yùn)維手工操作自動(dòng)化乘盖。這被許多人稱為DevOps革命。

這場革命使得開發(fā)團(tuán)隊(duì)和IT運(yùn)維人員通過使用Puppet憔涉、Chef和Docker等高級(jí)工具更加緊密地聯(lián)系在一起订框。意外地，Linux的變體允許免費(fèi)操作兜叨，開發(fā)人員可以在不受干擾的情況下將其組件部署到一個(gè)原始的操作系統(tǒng)穿扳。一整個(gè)可能的錯(cuò)誤類別就突然消失了，因?yàn)榻M件之間能夠相互解耦国旷。

如果開發(fā)人員可以構(gòu)建他們自己的現(xiàn)實(shí)環(huán)境矛物，他們必須減少與運(yùn)維部門的協(xié)調(diào)，也就減少了組織間的摩擦跪但。用程序啟動(dòng)類生產(chǎn)環(huán)境的能力消除了測試履羞、集成、共享環(huán)境下的資源競爭屡久、以及一系列其他問題忆首。

21世紀(jì)的架構(gòu)敏捷度

在治理方面，微服務(wù)架構(gòu)風(fēng)格有其他的好處被环。傳統(tǒng)的做法是糙及，企業(yè)架構(gòu)師定義了組織的共享技術(shù)棧，以最大化項(xiàng)目間的資源使用筛欢，同時(shí)最大程度地減少支撐成本浸锨。例如，一個(gè)大型企業(yè)可能將Java和Oracle標(biāo)準(zhǔn)化以作為其主要開發(fā)平臺(tái)悴能。如果每個(gè)人都使用Oracle揣钦，那么該企業(yè)的一切都可以存儲(chǔ)在一個(gè)工業(yè)強(qiáng)度的數(shù)據(jù)庫中。

規(guī)范化治理有一個(gè)缺點(diǎn)—通常漠酿，為了標(biāo)準(zhǔn)化的某一目的冯凹，團(tuán)隊(duì)必須使用并不太理想的工具。與此同時(shí)，還有一個(gè)潛在的更微妙的缺點(diǎn)宇姚。例如匈庭，考慮一個(gè)已經(jīng)選擇在特定消息隊(duì)列上標(biāo)準(zhǔn)化的大型企業(yè)。在評(píng)估需要此共享基礎(chǔ)設(shè)施的所有項(xiàng)目時(shí)浑劳，企業(yè)架構(gòu)師會(huì)找出最復(fù)雜的場景阱持，并選擇一個(gè)適合這種復(fù)雜度的工具來處理它們。

然而魔熏，許多項(xiàng)目并不具備這個(gè)最復(fù)雜的場景衷咽。但因?yàn)槊總€(gè)項(xiàng)目必須共享相同的基礎(chǔ)設(shè)施，所以每個(gè)團(tuán)隊(duì)都得承擔(dān)其他團(tuán)隊(duì)的最大復(fù)雜度蒜绽。這種情況也發(fā)生在數(shù)據(jù)庫層镶骗。許多項(xiàng)目只需要幾個(gè)記錄的簡單數(shù)據(jù)存儲(chǔ)，并不需要復(fù)雜的查詢功能躲雅，但最終都使用了具有工業(yè)強(qiáng)度的數(shù)據(jù)庫服務(wù)器鼎姊，只因?yàn)檫@個(gè)企業(yè)的標(biāo)準(zhǔn)如此。

容器化技術(shù)解決了這個(gè)問題相赁，因?yàn)樗h(yuǎn)離了共享基礎(chǔ)設(shè)施—每個(gè)項(xiàng)目都部署在自己原始的相寇、容器化的環(huán)境中。因?yàn)椴淮嬖诠蚕淼膭?dòng)力去選擇工具钮科，所以每個(gè)項(xiàng)目刻意選擇更適合自己的工具唤衫。

當(dāng)然，如果企業(yè)架構(gòu)師允許每個(gè)項(xiàng)目選擇自己的技術(shù)棧跺嗽，那么會(huì)存在一些嚴(yán)重的缺點(diǎn)战授。我們經(jīng)常看到一個(gè)稱之為““Goldilocks治理”（企業(yè)架構(gòu)師選擇幾個(gè)技術(shù)椊凹蓿—簡單、中等和復(fù)雜份帐，并根據(jù)規(guī)模分配新項(xiàng)目）的實(shí)踐璃吧，它適用于高度解耦的環(huán)境。這些知識(shí)是可遷移的废境，該公司仍然可以從中受益畜挨，但是卻可以遠(yuǎn)離那些由于疏忽大意而將問題過于復(fù)雜化的行為。

為什么我們會(huì)談到這兒噩凹？

Eric Evans的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書對(duì)微服務(wù)架構(gòu)發(fā)展產(chǎn)生了巨大的影響巴元。它介紹了一種將大問題空間分解為領(lǐng)域或重要實(shí)體（如客戶和訂單）及其關(guān)系（客戶下訂單）和行為的技術(shù)。領(lǐng)域定義的一部分是有關(guān)邊界上下文的概念：每個(gè)領(lǐng)域形成一個(gè)圍繞實(shí)現(xiàn)細(xì)節(jié)的封裝層驮宴。

例如逮刨，如果分析人員識(shí)別了一個(gè)Customer領(lǐng)域，那么它存在于自己的邊界上下文中堵泽。在Customer的上下文中修己，開發(fā)人員知道所有的實(shí)現(xiàn)細(xì)節(jié)：類結(jié)構(gòu)恢总，數(shù)據(jù)庫模式等。

但是睬愤，其他邊界上下文（如Orders）不能看到這些實(shí)現(xiàn)細(xì)節(jié)片仿。雖然領(lǐng)域可以為了協(xié)調(diào)的目的互相發(fā)送消息，但是任何一個(gè)領(lǐng)域都不能穿透另一個(gè)領(lǐng)域的邊界上下文尤辱。因此砂豌，在一個(gè)邊界上下文中的開發(fā)人員可以自由地更改實(shí)現(xiàn)，而不必?fù)?dān)心破壞其他領(lǐng)域光督。

微服務(wù)中的容器是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）中邊界上下文的物理表現(xiàn)：每個(gè)容器代表了一層封裝奸鸯，以防止實(shí)現(xiàn)細(xì)節(jié)干擾系統(tǒng)的其他部分。邊界上下文提供的隔離展示了結(jié)構(gòu)化軟件架構(gòu)的不同方式可帽。

在過去娄涩，設(shè)計(jì)架構(gòu)主要圍繞技術(shù)架構(gòu)：架構(gòu)模式、庫映跟、框架等蓄拣。例如，分層架構(gòu)在許多組織中是很常見的：

[圖1]傳統(tǒng)的分層架構(gòu)

在圖1中努隙，架構(gòu)師沿技術(shù)層進(jìn)行分離球恤，使之在需要時(shí)可以很容易地替換一整層的內(nèi)容。例如荸镊，如果開發(fā)人員需要更改持久機(jī)制咽斧，所有相關(guān)代碼都會(huì)出現(xiàn)在持久層中。

那么開發(fā)人員多久更換一次整個(gè)持久層呢躬存？幾乎從不张惹。但你的團(tuán)隊(duì)多長時(shí)間基于像Customer這樣的概念工作呢？每天岭洲！

在圖1分層架構(gòu)中宛逗，Customer處于哪一層呢？其中部分在表示層盾剩、業(yè)務(wù)層雷激、持久層等等。因此告私，項(xiàng)目架構(gòu)上通用單元的變化在分層架構(gòu)中并沒有得到很好的支持屎暇，原因是通用的變更影響到了每一層。

如果不同層代表了開發(fā)團(tuán)隊(duì)的不同部分驻粟，其影響會(huì)更嚴(yán)重根悼。例如，對(duì)Customer的更改可能涉及到用戶界面、業(yè)務(wù)邏輯番挺、持久層和其他特性唠帝。如果你的組織由開發(fā)人員、DBA玄柏、用戶界面設(shè)計(jì)師和運(yùn)維人員組成襟衰，而他們?cè)谙嗷ジ綦x的HR部門下，那么進(jìn)行常見更改的協(xié)調(diào)成本是巨大的粪摘。

微服務(wù)強(qiáng)調(diào)解耦和容器化瀑晒，翻轉(zhuǎn)了圖1中的傳統(tǒng)做法，使領(lǐng)域成為架構(gòu)的主要元素徘意，如圖2所示苔悦。

圖2：以領(lǐng)域?yàn)橹行牡募軜?gòu)

在圖2中，分層結(jié)構(gòu)仍然存在椎咧，但是其耦合邊界是領(lǐng)域的邊界玖详，它將技術(shù)架構(gòu)歸入實(shí)現(xiàn)細(xì)節(jié)，并用領(lǐng)域?qū)ζ溥M(jìn)行封裝勤讽。以技術(shù)為中心的組織單元中蟋座，員工與員工彼此隔離，要想在這樣的組織中構(gòu)建以領(lǐng)域?yàn)橹行牡募軜?gòu)是很難的脚牍。

許多技術(shù)人員在構(gòu)建數(shù)字化企業(yè)中會(huì)遇到這樣的問題：想要支持如移動(dòng)應(yīng)用等新舉措向臀，卻被那些需要拆分的遺留系統(tǒng)所拖累。如今诸狭，這些企業(yè)越來越多地引入微服務(wù)作為這種拆分過程的關(guān)鍵戰(zhàn)略楣号。

Greenfield項(xiàng)目得益于DDD實(shí)踐幌羞。通過DDD理解了他們的問題領(lǐng)域以及重要組件之間的接口所在。對(duì)于現(xiàn)有項(xiàng)目暂题，更加模塊化的系統(tǒng)會(huì)促使開發(fā)者解開事務(wù)性的泥球鄙早，并且可以在那些屬于一起的組件和偶然耦合的組件之間做更清楚地區(qū)分嫁盲。

團(tuán)隊(duì)

你還將遇到微服務(wù)對(duì)團(tuán)隊(duì)影響：一個(gè)架構(gòu)風(fēng)格是如何推動(dòng)開發(fā)團(tuán)隊(duì)重組的闹蒜。

1968年野哭，梅爾文·康威對(duì)軟件開發(fā)做了一個(gè)很有預(yù)見性的觀察，被稱為康威定律：

設(shè)計(jì)系統(tǒng)的組織眨唬，其產(chǎn)生的設(shè)計(jì)等價(jià)于這些組織間的溝通結(jié)構(gòu)。

康威定律對(duì)軟件開發(fā)的意義是什么呢好乐？你的設(shè)計(jì)反映了你的團(tuán)隊(duì)結(jié)構(gòu)匾竿。企業(yè)常見的團(tuán)隊(duì)結(jié)構(gòu)是由人力資源部門推動(dòng)的，他們將職能類似的技術(shù)專家組織在一起蔚万。雖然這是一種符合邏輯的排序算法岭妖，但這種結(jié)構(gòu)在設(shè)計(jì)自包含服務(wù)時(shí)效果不佳。

如我們認(rèn)為的康威逆定律，現(xiàn)在許多公司在圍繞業(yè)務(wù)領(lǐng)域組織跨職能團(tuán)隊(duì)昵慌，而不是圍繞技術(shù)分層構(gòu)建假夺。例如，一個(gè)Customer服務(wù)可能包括一個(gè)業(yè)務(wù)分析師斋攀、開發(fā)人員已卷、QA、UX淳蔼、DBA和運(yùn)維人員侧蘸。

團(tuán)隊(duì)會(huì)在準(zhǔn)備好之后再部署服務(wù)，而不是先構(gòu)建一些東西傳遞到運(yùn)維人員鹉梨，使之包含在下一個(gè)巨大的發(fā)布中讳癌。許多選擇微服務(wù)的公司使用持續(xù)部署，以盡快將變更投入生產(chǎn)環(huán)境中存皂。

總結(jié)

企業(yè)高管可能會(huì)認(rèn)為微服務(wù)是最新流行詞而不予考慮晌坤，但那些了解這種架構(gòu)影響的人可以獲得實(shí)實(shí)在在的好處。微服務(wù)可以提高交付速度旦袋，增強(qiáng)靈活性骤菠，并提高效率。他們將工作進(jìn)行重組猜憎，并與業(yè)務(wù)問題域保持一致娩怎，而不是技術(shù)域；從一組獨(dú)立胰柑，更易于開發(fā)和維護(hù)的服務(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競爭力看作魯棒性一個(gè)新的度量崩瓤。對(duì)于這些企業(yè)來說，未來已經(jīng)在這里了踩官。其他還沒有意識(shí)到這一點(diǎn)的公司可能會(huì)發(fā)現(xiàn)他們的未來已經(jīng)受到了影響却桶。

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