在前文中我們說到，傳統(tǒng)企業(yè)在逐步建設(shè)自己的數(shù)字平臺過程中，需要抓住交付基礎(chǔ)設(shè)施、API和架構(gòu)治理、數(shù)據(jù)自服務(wù)、創(chuàng)新實(shí)驗(yàn)基礎(chǔ)設(shè)施和監(jiān)控體系、用戶觸點(diǎn)技術(shù)這五個支柱。今天我們就來談一談API、架構(gòu)治理這些聽起來非常技術(shù)性的概念與企業(yè)的數(shù)字化戰(zhàn)略之間有何關(guān)系。

[[212827]]

一、企業(yè)資源服務(wù)化

從1990年代起，企業(yè)資源計(jì)劃(ERP)一直是企業(yè)信息化的核心議題。植根于供應(yīng)鏈管理，ERP通過對企業(yè)內(nèi)部財(cái)務(wù)會計(jì)、制造、進(jìn)銷存等信息流的整合，提升企業(yè)的計(jì)劃能力與控制能力。然而近年來，在互聯(lián)網(wǎng)的沖擊下，傳統(tǒng)企業(yè)開始面臨全新的挑戰(zhàn)。尤其是在互聯(lián)網(wǎng)的去中介化效應(yīng)影響下，原本在供應(yīng)鏈上下游各安其位的企業(yè)突然間都被壓縮到了“生產(chǎn)-流通-消費(fèi)”這個極度精簡的價值鏈中。藥品購銷兩票制就是這個極簡價值模型的直觀呈現(xiàn)。在這個模型中，掌握技術(shù)優(yōu)勢和消費(fèi)者入口的互聯(lián)網(wǎng)企業(yè)有可能形成一家獨(dú)大的超級壟斷，擠死傳統(tǒng)的流通企業(yè)，把生產(chǎn)企業(yè)變成自己的OEM廠商，這是傳統(tǒng)企業(yè)對來自互聯(lián)網(wǎng)的競爭者恐懼的根源。

為了對抗互聯(lián)網(wǎng)企業(yè)的競爭，傳統(tǒng)企業(yè)最好的辦法不是硬拼互聯(lián)網(wǎng)上的技術(shù)和流量，而是在自己擅長的領(lǐng)域開戰(zhàn)：把自己多年積累的線下資源變成線上服務(wù)，構(gòu)建起本行業(yè)的線上生態(tài)系統(tǒng)，不僅支撐本企業(yè)的線上經(jīng)營，而且為上下游周邊企業(yè)提供線上經(jīng)營的平臺，從而把線下優(yōu)勢轉(zhuǎn)化為線上優(yōu)勢，以資源優(yōu)勢對抗技術(shù)優(yōu)勢。

為了支撐企業(yè)資源的服務(wù)化，在設(shè)計(jì)在線服務(wù)的API和架構(gòu)時需要考慮以下問題：

• 平臺架構(gòu)和API的設(shè)計(jì)應(yīng)該注重開發(fā)者體驗(yàn)。
• 在API的背后，應(yīng)該從業(yè)務(wù)功能的角度出發(fā)劃分合理的限界上下文和服務(wù)邊界，對外提供高內(nèi)聚低耦合的服務(wù)。
• 在服務(wù)邊界之間，應(yīng)該考慮使用異步的事件機(jī)制實(shí)現(xiàn)服務(wù)之間的通信，來解耦領(lǐng)域模型，客觀地描述運(yùn)行時間比較長、甚至本質(zhì)上不可能立即完成的操作。
• 為了方便使用，應(yīng)該提供API網(wǎng)關(guān)作為所有服務(wù)使用者的單一入口，在API網(wǎng)關(guān)背后去處理眾多內(nèi)部IT系統(tǒng)的復(fù)雜性。
• 整個API架構(gòu)應(yīng)該以微服務(wù)的風(fēng)格呈現(xiàn)，避免典型SOA架構(gòu)中普遍存在的過于復(fù)雜的ESB編排邏輯。

ERP之后是什么?

進(jìn)入2010年代以來，“后ERP時代”這個說法不斷被提出。在談到ERP的發(fā)展方向時，通常都會涉及業(yè)務(wù)與技術(shù)兩個角度。例如一種觀點(diǎn)認(rèn)為，ERP需要從以流程為中心轉(zhuǎn)變?yōu)橐钥蛻魹橹行模⑶倚枰煤迷朴?jì)算、社交網(wǎng)絡(luò)、大數(shù)據(jù)和移動化等新技術(shù)。

ThoughtWorks認(rèn)為，ERP在互聯(lián)網(wǎng)時代的發(fā)展方向?qū)⑹瞧髽I(yè)資源服務(wù)化(Enterprise Resource Servicification，ERS)，通過數(shù)字平臺的技術(shù)能力，把一家企業(yè)的資源融入一個行業(yè)的互聯(lián)網(wǎng)生態(tài)，為企業(yè)鋪下明確的數(shù)字化道路。

二、API和架構(gòu)治理解讀

下面我們來近距離看看，在“API和架構(gòu)治理”這頂帽子下面，有哪些具體的問題需要被考慮到。

1. 開發(fā)者體驗(yàn)

當(dāng)企業(yè)資源以服務(wù)的形式對外提供，也就意味著不可能——像傳統(tǒng)的IT系統(tǒng)建設(shè)那樣——強(qiáng)迫別人使用這些服務(wù)。尤其是要把這些服務(wù)提供給第三方開發(fā)者、希望他們開發(fā)出形形色色的應(yīng)用程序，那么服務(wù)的API是否易用就會很大程度上影響它能吸引到多少第三方開發(fā)者。

在討論開發(fā)者體驗(yàn)時，可以從開發(fā)工具和開發(fā)環(huán)境的安裝、配置、管理、使用、維護(hù)等角度來考量。具體而言，開發(fā)環(huán)境和測試環(huán)境是否能彈性地隨需獲得，開發(fā)/測試基礎(chǔ)設(shè)施和持續(xù)交付流水線是否以源代碼的形式提供并完全自動化，是否提供對主流開源軟件的支持，是否提供可編程的、命令行友好的(而不僅僅是圖形化的)工具界面，安全、數(shù)據(jù)訪問權(quán)限等企業(yè)規(guī)章是否嚴(yán)重影響開發(fā)者的效率和感受，這些都是影響開發(fā)者體驗(yàn)的要素。

2. 服務(wù)邊界

和所有的面向?qū)ο笤O(shè)計(jì)一樣，服務(wù)的設(shè)計(jì)應(yīng)該是高內(nèi)聚低耦合的：與一個業(yè)務(wù)相關(guān)的修改只在一個服務(wù)內(nèi)部進(jìn)行，并且一個服務(wù)的修改/部署不需要影響其他服務(wù)。和一個代碼庫內(nèi)部的對象設(shè)計(jì)不同，每個服務(wù)通常有專屬的代碼庫，并且由專人負(fù)責(zé)維護(hù)(而不是所有人擁有所有代碼)，因此服務(wù)邊界的改變會帶來更大的變更成本。所以，服務(wù)邊界的劃分需要投入精力認(rèn)真對待。

[[212828]]

從設(shè)計(jì)原則上來說，服務(wù)的邊界應(yīng)該體現(xiàn)業(yè)務(wù)的邊界，而不是單純從技術(shù)角度出發(fā)劃分服務(wù)邊界。從業(yè)務(wù)功能的角度出發(fā)劃分合理的限界上下文，以領(lǐng)域模型和領(lǐng)域事件的聚合為出發(fā)點(diǎn)來劃分服務(wù)，更可能得出與業(yè)務(wù)邊界一致的服務(wù)邊界。隨后再以業(yè)務(wù)目標(biāo)驅(qū)動建設(shè)全功能一體化團(tuán)隊(duì)，就能做到業(yè)務(wù)、技術(shù)、團(tuán)隊(duì)三者對齊(康威定律再次起作用)。四色建模、事件風(fēng)暴等方法都能有效地實(shí)現(xiàn)領(lǐng)域驅(qū)動設(shè)計(jì)，從而建立起良好的領(lǐng)域模型及服務(wù)邊界。

3. 事件驅(qū)動架構(gòu)

使用異步的事件機(jī)制實(shí)現(xiàn)服務(wù)之間的通信。對于運(yùn)行時間比較長、甚至本質(zhì)上不可能立即完成的操作(例如涉及人工操作)，使用異步通信是合理的選擇。即便不考慮響應(yīng)的實(shí)時性，事件驅(qū)動的架構(gòu)還表達(dá)了領(lǐng)域模型之間的松散耦合關(guān)系：跨領(lǐng)域的協(xié)作以事件而非方法調(diào)用的形式來表達(dá)，系統(tǒng)追求最終一致性而非強(qiáng)一致性。這一結(jié)構(gòu)準(zhǔn)確地映射了真實(shí)世界中多支相關(guān)但獨(dú)立的團(tuán)隊(duì)之間的協(xié)作關(guān)系，避免了過度依賴其他服務(wù)的響應(yīng)速度或可靠性等服務(wù)質(zhì)量指標(biāo)，使服務(wù)真正具有技術(shù)上的獨(dú)立性。

在設(shè)計(jì)系統(tǒng)時，借助事件風(fēng)暴方法，可以通過領(lǐng)域事件識別出聚合根，進(jìn)而劃分微服務(wù)的限界上下文。當(dāng)出現(xiàn)跨多個聚合根的事件時，可以很自然地將其實(shí)現(xiàn)為異步的領(lǐng)域事件，從而獲得與領(lǐng)域設(shè)計(jì)高度吻合的實(shí)現(xiàn)。

在實(shí)現(xiàn)事件驅(qū)動的架構(gòu)時，當(dāng)然可以沿用傳統(tǒng)的SOA架構(gòu)中的消息中間件。但由于微服務(wù)架構(gòu)中，業(yè)務(wù)邏輯都存在于各個服務(wù)內(nèi)部，沒有龐大臃腫的ESB(稍后我們還會詳談這個問題)，因此消息機(jī)制也不需要強(qiáng)大的服務(wù)編排(orchestration)能力。RabbitMQ這樣標(biāo)準(zhǔn)的消息代理當(dāng)然很好，也有很多系統(tǒng)(例如Bahmni)采用更簡單的做法：領(lǐng)域事件發(fā)生時，以ATOM格式發(fā)布;關(guān)心特定領(lǐng)域事件的其他領(lǐng)域模型則訂閱特定的ATOM feed主題。這種基于HTTP的事件傳播方式最大的好處就是簡單，幾乎不需要增加新的軟件就可以實(shí)現(xiàn)。不過這個方案在處理低延遲的場景時表現(xiàn)不佳。

4. 公共網(wǎng)關(guān)

微服務(wù)提供的API粒度與客戶端的需求不同，所以客戶端一個請求經(jīng)常需要多個服務(wù);服務(wù)端和客戶端之間可能需要通信協(xié)議轉(zhuǎn)換;不同的客戶端對數(shù)據(jù)的需求不同，例如瀏覽器客戶端需要的信息可能多于移動客戶端;服務(wù)的終端信息(主機(jī)+端口)可能變化;不同數(shù)據(jù)片可能由不同的服務(wù)終端來提供——以上這些因素都指出：有必要對服務(wù)做一層門面封裝，提供API網(wǎng)關(guān)作為所有服務(wù)使用者的單一入口點(diǎn)。

API網(wǎng)關(guān)處理請求的方式有兩種：一種是直接代理/路由給合適的服務(wù);另一種是由一個請求扇出/分發(fā)給多個服務(wù)。API網(wǎng)關(guān)可能針對不同客戶端提供不同的API，可能包含針對客戶端的適配代碼。橫切需求(例如安全)也可能在API網(wǎng)關(guān)實(shí)現(xiàn)。

當(dāng)服務(wù)數(shù)量變多、API網(wǎng)關(guān)變大以后，維護(hù)一個通用的API網(wǎng)關(guān)會增加API網(wǎng)關(guān)層的復(fù)雜度，導(dǎo)致一個獨(dú)立的“API團(tuán)隊(duì)”出現(xiàn)，協(xié)調(diào)和溝通的工作量加大。這時可以考慮引入公共網(wǎng)關(guān)的一個變體：為特定前端設(shè)計(jì)的后端(Backend For Frontend，BFF)，即為每個前端應(yīng)用提供一個單獨(dú)的API網(wǎng)關(guān)，使對齊業(yè)務(wù)的一體化團(tuán)隊(duì)能夠拉通前后端開發(fā)、而不必等待“API團(tuán)隊(duì)”完成他們的backlog。

API網(wǎng)關(guān)可以實(shí)現(xiàn)為一個獨(dú)立的服務(wù)端應(yīng)用，其代價則是增加一層復(fù)雜度(和出錯的可能性)。為了降低這一代價，可以考慮用Zuul等工具來實(shí)現(xiàn)API網(wǎng)關(guān)。

5. 微服務(wù)SOA拓?fù)?/strong>