原文于2017年2月22日發(fā)表于思特沃克洞見(jiàn)

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

未來(lái)已經(jīng)在這里酬诀，它只是分布不均。- 威廉·吉布森
數(shù)字時(shí)代就在我們身邊骆撇。將軟件開(kāi)發(fā)視為高成本開(kāi)銷(xiāo)而不是競(jìng)爭(zhēng)力的企業(yè)將會(huì)艱難前行瞒御。為了參與并在這個(gè)數(shù)字世界中繁榮興旺，企業(yè)必須學(xué)會(huì)適應(yīng)我們這個(gè)時(shí)代的不確定性—更快地將新產(chǎn)品推向市場(chǎng)神郊，快速而有效地加強(qiáng)當(dāng)前的產(chǎn)品肴裙，并為客戶提供有意義的數(shù)字體驗(yàn)趾唱。
為了實(shí)現(xiàn)這些目標(biāo)，企業(yè)需要將敏捷性/適應(yīng)性集成到三個(gè)領(lǐng)域：人蜻懦，流程和技術(shù)甜癞。
人們需要適應(yīng)試驗(yàn)和改變。過(guò)程需要迭代式進(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)該注意些什么技術(shù)呢渡贾？
這個(gè)問(wèn)題的答案被那些不停地討論看似神秘話題的技術(shù)人員們所掩蓋。哪些神秘的話題需要得到管理層的注意呢雄右？其中最重要的話題之一是微服務(wù)空骚。其中的原因如下所述：
微服務(wù)影響人，流程和技術(shù)：包括團(tuán)隊(duì)組織結(jié)構(gòu)擂仍，流程和實(shí)踐（如DevOps）囤屹，以及重新調(diào)整架構(gòu)以適應(yīng)我們要解決的問(wèn)題，而這些并非在技術(shù)層面逢渔。微服務(wù)促進(jìn)了每個(gè)領(lǐng)域的適應(yīng)性肋坚。它值得管理層花時(shí)間去了解潛在的貢獻(xiàn)。

技術(shù)敏捷度

微服務(wù)架構(gòu)風(fēng)格的特性是由一組極小的服務(wù)組成肃廓，它們彼此互相獨(dú)立且單獨(dú)部署智厌。微服務(wù)由Netflix這樣的公司推廣開(kāi)來(lái)。每個(gè)服務(wù)包含一個(gè)離散的業(yè)務(wù)功能盲赊，它在技術(shù)上與其他服務(wù)相隔離铣鹏，產(chǎn)生了類(lèi)似樂(lè)高積木的效果：開(kāi)發(fā)人員可以將服務(wù)切換為一個(gè)新的服務(wù)，而無(wú)需破壞其他服務(wù)哀蘑。就像巨型的樂(lè)高模型可以有75,000塊樂(lè)高诚卸，大型的數(shù)字應(yīng)用程序也可以由這些受樂(lè)高思想啟發(fā)的服務(wù)所構(gòu)建。
這種架構(gòu)有一些明顯的好處绘迁。首先合溺，每個(gè)服務(wù)與其他服務(wù)高度解耦，這意味著它們是自包含的缀台。因此棠赛，一個(gè)服務(wù)中的技術(shù)更改（例如數(shù)據(jù)結(jié)構(gòu)更改）不會(huì)影響另一個(gè)服務(wù)。服務(wù)仍然可以通過(guò)消息傳遞進(jìn)行通信，但是任何一個(gè)服務(wù)都不允許修改另一個(gè)服務(wù)的實(shí)現(xiàn)細(xì)節(jié)恭朗。
第二，因?yàn)殚_(kāi)發(fā)人員不需要共享基礎(chǔ)設(shè)施依疼，他們可以選用適合于該問(wèn)題復(fù)雜度的技術(shù)棧來(lái)實(shí)現(xiàn)每一個(gè)服務(wù)痰腮。考慮到當(dāng)今技術(shù)棧的復(fù)雜性律罢，在同一應(yīng)用程序中膀值，使用簡(jiǎn)單工具處理簡(jiǎn)單問(wèn)題和使用復(fù)雜工具處理復(fù)雜問(wèn)題的能力使開(kāi)發(fā)團(tuán)隊(duì)增加了靈活性并降低了成本。領(lǐng)導(dǎo)者重視能將復(fù)雜問(wèn)題簡(jiǎn)化的技術(shù)專家误辑。
第三沧踏，每個(gè)服務(wù)封裝了業(yè)務(wù)功能，它使得形成圍繞特定問(wèn)題域的團(tuán)隊(duì)更容易巾钉，而不是通過(guò)作業(yè)功能分割的團(tuán)隊(duì)翘狱。例如，服務(wù)團(tuán)隊(duì)通常包括開(kāi)發(fā)人員砰苍、業(yè)務(wù)分析師潦匈、DBA、運(yùn)維人員和QA—即構(gòu)建和部署服務(wù)所需的一切角色赚导。而這反過(guò)來(lái)減少了協(xié)調(diào)成本茬缩。
從功能性組織結(jié)構(gòu)向產(chǎn)品或服務(wù)結(jié)構(gòu)轉(zhuǎn)變是敏捷企業(yè)轉(zhuǎn)型的一個(gè)日益增長(zhǎng)的趨勢(shì)。而微服務(wù)架構(gòu)支持了這種趨勢(shì)的變化吼旧。
最后凰锡，因?yàn)槊總€(gè)服務(wù)是相互隔離的，所以以服務(wù)組成的架構(gòu)既快速又靈活圈暗。同時(shí)因?yàn)榉?wù)的業(yè)務(wù)范圍很小掂为，對(duì)服務(wù)的更改可以快速地發(fā)生，這為開(kāi)發(fā)人員提供了新的高級(jí)功能员串。一旦架構(gòu)師設(shè)計(jì)了一個(gè)小型獨(dú)立服務(wù)的系統(tǒng)菩掏，其中應(yīng)用程序由部署的多個(gè)服務(wù)之間的消息傳遞組成，多變量測(cè)試等能力就變得容易了昵济。
例如智绸，企業(yè)可能對(duì)他們網(wǎng)站的未來(lái)方向并不確定。因此他們?cè)O(shè)計(jì)了具有相似但不同功能的兩種服務(wù)访忿，并向不同的用戶組部署不同的版本瞧栗，以獲取結(jié)果從而推動(dòng)未來(lái)發(fā)展的方向。像Facebook這樣的公司也是通過(guò)使用這種類(lèi)型的A / B測(cè)試進(jìn)行試驗(yàn)來(lái)分析他們的用戶海铆。
標(biāo)準(zhǔn)化一直是IT組織作為降低成本方式之一的口頭禪迹恐。不幸的是，它也降低了靈活性—標(biāo)準(zhǔn)化越多卧斟，靈活性越少殴边。通過(guò)采納微服務(wù)架構(gòu)憎茂，架構(gòu)師和開(kāi)發(fā)人員可以使用更加多樣化且能夠緊密反映問(wèn)題復(fù)雜度的技術(shù)棧來(lái)設(shè)計(jì)應(yīng)用程序。
微服務(wù)架構(gòu)風(fēng)格與許多企業(yè)部署軟件和分配IT資源的方式相反锤岸。許多架構(gòu)風(fēng)格的主要目標(biāo)之一是有效地利用共享資源（操作系統(tǒng)竖幔、數(shù)據(jù)庫(kù)服務(wù)器、應(yīng)用程序服務(wù)器等）是偷。由于資源的成本影響了底線拳氢，因此這些公司建立了軟件架構(gòu)以最大化共享資源。
然而蛋铆，共享資源有一個(gè)缺點(diǎn)馋评。無(wú)論開(kāi)發(fā)人員如何有效地構(gòu)建與這些服務(wù)器的隔離，都會(huì)出現(xiàn)對(duì)這些資源的競(jìng)爭(zhēng)刺啦。有時(shí)組件由于依賴管理而互相干擾留特，有時(shí)由于兩個(gè)組件爭(zhēng)用某些資源（例如CPU）而產(chǎn)生問(wèn)題。這就不可避免地引起共享組件以并不期望的方式進(jìn)行交互玛瘸。

容器和解耦

在軟件交付中磕秤，有兩個(gè)關(guān)鍵的技術(shù)“環(huán)境”：開(kāi)發(fā)人員工作的開(kāi)發(fā)環(huán)境，以及IT運(yùn)維人員管轄范圍的部署環(huán)境捧韵。傳統(tǒng)情況下市咆，在這兩個(gè)環(huán)境之間移動(dòng)代碼充滿了技術(shù)錯(cuò)誤，冗長(zhǎng)的時(shí)間延遲以及組織層面的溝通不暢再来。
幾年前蒙兰，一些有趣的事情發(fā)生了：Linux對(duì)于大多數(shù)企業(yè)足夠友好，Linux的變體在商業(yè)上免費(fèi)—但是這不足以影響技術(shù)架構(gòu)芒篷。
接下來(lái)搜变，開(kāi)源的創(chuàng)新與敏捷開(kāi)發(fā)技術(shù)的結(jié)合鼓勵(lì)了開(kāi)發(fā)人員創(chuàng)建各種工具，將許多繁瑣的運(yùn)維手工操作自動(dòng)化针炉。這被許多人稱為DevOps革命挠他。
這場(chǎng)革命使得開(kāi)發(fā)團(tuán)隊(duì)和IT運(yùn)維人員通過(guò)使用Puppet、Chef和Docker等高級(jí)工具更加緊密地聯(lián)系在一起篡帕。意外地殖侵，Linux的變體允許免費(fèi)操作，開(kāi)發(fā)人員可以將其組件部署到一個(gè)原始的操作系統(tǒng)镰烧，沒(méi)有別的干擾因素拢军。一整個(gè)可能的錯(cuò)誤類(lèi)別就突然消失了，因?yàn)榻M件之間相互解耦怔鳖。
如果開(kāi)發(fā)人員可以構(gòu)建他們自己的現(xiàn)實(shí)環(huán)境茉唉，他們必須減少與運(yùn)維部門(mén)的協(xié)調(diào)，從而減少了組織間的摩擦。用程序啟動(dòng)類(lèi)生產(chǎn)環(huán)境的能力消除了測(cè)試度陆、集成艾凯、共享環(huán)境下的資源競(jìng)爭(zhēng)、以及一系列其他問(wè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)化以作為其主要開(kāi)發(fā)平臺(tái)杈笔。如果每個(gè)人都使用Oracle闪水，那么該企業(yè)的一切都可以存儲(chǔ)在一個(gè)工業(yè)強(qiáng)度的數(shù)據(jù)庫(kù)中。
規(guī)范化治理有一個(gè)缺點(diǎn)—通常蒙具，為了標(biāo)準(zhǔn)化的某一目的球榆，團(tuán)隊(duì)必須使用并不太理想的工具。但還有一個(gè)潛在的更微妙的缺點(diǎn)禁筏。例如持钉，考慮一個(gè)已經(jīng)選擇在特定消息隊(duì)列上標(biāo)準(zhǔn)化的大型企業(yè)。在評(píng)估需要此共享基礎(chǔ)設(shè)施的所有項(xiàng)目時(shí)篱昔，企業(yè)架構(gòu)師會(huì)找出最復(fù)雜的場(chǎng)景每强，并選擇一個(gè)適合這種復(fù)雜度的工具來(lái)處理它們。
然而州刽，許多項(xiàng)目并不具備這個(gè)最復(fù)雜的場(chǎng)景空执。但因?yàn)槊總€(gè)項(xiàng)目必須共享相同的基礎(chǔ)設(shè)施，所以每個(gè)團(tuán)隊(duì)承擔(dān)了其他團(tuán)隊(duì)的最大復(fù)雜度穗椅。這也發(fā)生在數(shù)據(jù)庫(kù)層辨绊。許多項(xiàng)目只需要一個(gè)有幾個(gè)記錄的簡(jiǎn)單數(shù)據(jù)存儲(chǔ)，并不需要復(fù)雜的查詢功能匹表，但最終都使用了具有工業(yè)強(qiáng)度的數(shù)據(jù)庫(kù)服務(wù)器门坷，只因?yàn)樗沁@個(gè)企業(yè)的標(biāo)準(zhǔn)。
容器化技術(shù)解決了這個(gè)問(wèn)題袍镀，因?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ù)棧—簡(jiǎn)單蜻势、中等和復(fù)雜撑刺，并根據(jù)規(guī)模分配新項(xiàng)目）的實(shí)踐，它適用于高度解耦的環(huán)境握玛。這些知識(shí)是可遷移的够傍，該公司仍然可以從中受益，但是卻可以遠(yuǎn)離那些由于疏忽大意而將問(wèn)題過(guò)于復(fù)雜化的行為挠铲。

為什么我們會(huì)談到這兒冕屯？

Eric Evans的“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”一書(shū)是對(duì)微服務(wù)架構(gòu)的另一個(gè)巨大影響。它是一種將大問(wè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的上下文中，開(kāi)發(fā)人員知道所有的實(shí)現(xiàn)細(xì)節(jié)：類(lèi)結(jié)構(gòu)脯宿，數(shù)據(jù)庫(kù)模式等念颈。
但是，其他邊界上下文（如Orders）不能看到這些實(shí)現(xiàn)細(xì)節(jié)连霉。雖然領(lǐng)域可以為了協(xié)調(diào)的目的互相發(fā)送消息舍肠，但是任何一個(gè)領(lǐng)域都不能穿透另一個(gè)的邊界上下文。因此窘面，在一個(gè)邊界上下文中的開(kāi)發(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)的不同方式。
在過(guò)去酣难，設(shè)計(jì)架構(gòu)主要圍繞技術(shù)架構(gòu)：架構(gòu)模式谍夭，庫(kù)，框架等憨募。例如紧索，分層架構(gòu)在許多組織中是很常見(jiàn)的：
[站外圖片上傳中...(image-7158b5-1535352075412)]
[圖1]傳統(tǒng)的分層架構(gòu)
在圖1中，架構(gòu)師沿技術(shù)層進(jìn)行分離菜谣，使得在需要時(shí)可以容易地替換一整層的內(nèi)容珠漂。例如晚缩，如果開(kāi)發(fā)人員需要更改持久機(jī)制，所有相關(guān)代碼都會(huì)出現(xiàn)在持久層中媳危。
那么開(kāi)發(fā)人員多久更換一次整個(gè)持久層呢荞彼？幾乎從不。但你的團(tuán)隊(duì)多長(zhǎng)時(shí)間基于像Customer這樣的概念工作呢待笑？每天鸣皂！
在圖1分層架構(gòu)中，Customer處于哪一層呢暮蹂？其中部分在表示層寞缝，業(yè)務(wù)層，持久層等等仰泻。因此荆陆，項(xiàng)目架構(gòu)上通用單元的變化在分層架構(gòu)中并沒(méi)有得到很好的支持，原因是通用的變更影響到了每一層我纪。
如果不同層代表了開(kāi)發(fā)團(tuán)隊(duì)的不同部分慎宾，其影響會(huì)更嚴(yán)重丐吓。例如浅悉，對(duì)Customer的更改可能需要更改用戶界面，業(yè)務(wù)邏輯券犁，持久層和其他特性术健。如果你的組織有開(kāi)發(fā)人員，DBA粘衬，用戶界面設(shè)計(jì)師和運(yùn)維人員組成荞估，而他們?cè)谙嗷ジ綦x的HR部門(mén)下，那么進(jìn)行常見(jiàn)更改的協(xié)調(diào)成本是巨大的稚新。
微服務(wù)強(qiáng)調(diào)解耦和容器化勘伺，翻轉(zhuǎn)了圖1中的傳統(tǒng)做法，使領(lǐng)域成為架構(gòu)的主要元素褂删，如圖2所示飞醉。
[站外圖片上傳中...(image-7e9dab-1535352075412)]
圖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è)中遇到的的重要問(wèn)題之一是為了支持如移動(dòng)應(yīng)用等新舉措?yún)s被那些需要拆分的遺留系統(tǒng)所拖累盖袭。如今失暂，這些企業(yè)越來(lái)越多地使用微服務(wù)作為這種拆分過(guò)程的關(guān)鍵戰(zhàn)略彼宠。
Greenfield項(xiàng)目得益于DDD實(shí)踐。通過(guò)DDD理解了他們的問(wèn)題領(lǐng)域以及重要組件之間的接口所在趣席。對(duì)于現(xiàn)有項(xiàng)目兵志，更加模塊化的系統(tǒng)會(huì)促使開(kāi)發(fā)者解開(kāi)事務(wù)性的泥球，并且可以在那些屬于一起的組件和偶然耦合的組件之間做更清楚地區(qū)分宣肚。

團(tuán)隊(duì)

你還將遇到微服務(wù)對(duì)團(tuán)隊(duì)影響：一個(gè)架構(gòu)風(fēng)格是如何推動(dòng)開(kāi)發(fā)團(tuán)隊(duì)的重組想罕。
1968年，梅爾文·康威對(duì)軟件開(kāi)發(fā)做了一個(gè)很有預(yù)見(jiàn)性的觀察霉涨，被稱為康威定律：

設(shè)計(jì)系統(tǒng)的組織...其產(chǎn)生的設(shè)計(jì)等價(jià)于這些組織間的溝通結(jié)構(gòu)按价。
康威定律對(duì)軟件開(kāi)發(fā)的意義是什么呢？你的設(shè)計(jì)反映了你的團(tuán)隊(duì)結(jié)構(gòu)笙瑟。企業(yè)常見(jiàn)的團(tuán)隊(duì)結(jié)構(gòu)是由人力資源部門(mén)推動(dòng)的楼镐，他們將類(lèi)似的技術(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ù)分析師屯碴，開(kāi)發(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ù)問(wèn)題域保持一致铲掐，而不是技術(shù)域拾弃；從一組獨(dú)立，更易于開(kāi)發(fā)和維護(hù)的服務(wù)中創(chuàng)建業(yè)務(wù)應(yīng)用程序摆霉；更好地匹配技術(shù)解決方案與業(yè)務(wù)問(wèn)題的復(fù)雜程度豪椿；構(gòu)建可以幫助重組現(xiàn)有遺留系統(tǒng)以及創(chuàng)建能夠快速響應(yīng)不斷變化的業(yè)務(wù)條件的新產(chǎn)品和服務(wù)的自適應(yīng)架構(gòu)奔坟。
威廉·吉布森是正確的—許多公司已經(jīng)將IT競(jìng)爭(zhēng)力看作魯棒性一個(gè)新的度量。對(duì)于這些企業(yè)來(lái)說(shuō)搭盾，未來(lái)已經(jīng)在這里了咳秉。其他還沒(méi)有意識(shí)到這一點(diǎn)的公司可能會(huì)發(fā)現(xiàn)他們的未來(lái)已經(jīng)收到了影響。
原文鏈接：https://www.thoughtworks.com/cn/insights/blog/cxo-guide-microservices
**