數字化企業的API架構治理
在前文中我們說到，傳統企業在逐步建設自己的數字平臺過程中，需要抓住交付基礎設施、API和架構治理、數據自服務、創新實驗基礎設施和監控體系、用戶觸點技術這五個支柱。今天我們就來談一談API、架構治理這些聽起來非常技術性的概念與企業的數字化戰略之間有何關系。
一、企業資源服務化
從1990年代起，企業資源計劃(ERP)一直是企業信息化的核心議題。植根于供應鏈管理，ERP通過對企業內部財務會計、制造、進銷存等信息流的整合，提升企業的計劃能力與控制能力。然而近年來，在互聯網的沖擊下，傳統企業開始面臨全新的挑戰。尤其是在互聯網的去中介化效應影響下，原本在供應鏈上下游各安其位的企業突然間都被壓縮到了“生產-流通-消費”這個極度精簡的價值鏈中。藥品購銷兩票制就是這個極簡價值模型的直觀呈現。在這個模型中，掌握技術優勢和消費者入口的互聯網企業有可能形成一家獨大的超級壟斷，擠死傳統的流通企業，把生產企業變成自己的OEM廠商，這是傳統企業對來自互聯網的競爭者恐懼的根源。
為了對抗互聯網企業的競爭，傳統企業最好的辦法不是硬拼互聯網上的技術和流量，而是在自己擅長的領域開戰：把自己多年積累的線下資源變成線上服務，構建起本行業的線上生態系統，不僅支撐本企業的線上經營，而且為上下游周邊企業提供線上經營的平臺，從而把線下優勢轉化為線上優勢，以資源優勢對抗技術優勢。
為了支撐企業資源的服務化，在設計在線服務的API和架構時需要考慮以下問題：
- 平臺架構和API的設計應該注重開發者體驗。
- 在API的背后，應該從業務功能的角度出發劃分合理的限界上下文和服務邊界，對外提供高內聚低耦合的服務。
- 在服務邊界之間，應該考慮使用異步的事件機制實現服務之間的通信，來解耦領域模型，客觀地描述運行時間比較長、甚至本質上不可能立即完成的操作。
- 為了方便使用，應該提供API網關作為所有服務使用者的單一入口，在API網關背后去處理眾多內部IT系統的復雜性。
- 整個API架構應該以微服務的風格呈現，避免典型SOA架構中普遍存在的過于復雜的ESB編排邏輯。
ERP之后是什么?
進入2010年代以來，“后ERP時代”這個說法不斷被提出。在談到ERP的發展方向時，通常都會涉及業務與技術兩個角度。例如一種觀點認為，ERP需要從以流程為中心轉變為以客戶為中心，并且需要用好云計算、社交網絡、大數據和移動化等新技術。
ThoughtWorks認為，ERP在互聯網時代的發展方向將是企業資源服務化(Enterprise Resource Servicification，ERS)，通過數字平臺的技術能力，把一家企業的資源融入一個行業的互聯網生態，為企業鋪下明確的數字化道路。
二、API和架構治理解讀
下面我們來近距離看看，在“API和架構治理”這頂帽子下面，有哪些具體的問題需要被考慮到。
1. 開發者體驗
當企業資源以服務的形式對外提供，也就意味著不可能——像傳統的IT系統建設那樣——強迫別人使用這些服務。尤其是要把這些服務提供給第三方開發者、希望他們開發出形形色色的應用程序，那么服務的API是否易用就會很大程度上影響它能吸引到多少第三方開發者。
在討論開發者體驗時，可以從開發工具和開發環境的安裝、配置、管理、使用、維護等角度來考量。具體而言，開發環境和測試環境是否能彈性地隨需獲得，開發/測試基礎設施和持續交付流水線是否以源代碼的形式提供并完全自動化，是否提供對主流開源軟件的支持，是否提供可編程的、命令行友好的(而不僅僅是圖形化的)工具界面，安全、數據訪問權限等企業規章是否嚴重影響開發者的效率和感受，這些都是影響開發者體驗的要素。
2. 服務邊界
和所有的面向對象設計一樣，服務的設計應該是高內聚低耦合的：與一個業務相關的修改只在一個服務內部進行，并且一個服務的修改/部署不需要影響其他服務。和一個代碼庫內部的對象設計不同，每個服務通常有專屬的代碼庫，并且由專人負責維護(而不是所有人擁有所有代碼)，因此服務邊界的改變會帶來更大的變更成本。所以，服務邊界的劃分需要投入精力認真對待。
從設計原則上來說，服務的邊界應該體現業務的邊界，而不是單純從技術角度出發劃分服務邊界。從業務功能的角度出發劃分合理的限界上下文，以領域模型和領域事件的聚合為出發點來劃分服務，更可能得出與業務邊界一致的服務邊界。隨后再以業務目標驅動建設全功能一體化團隊，就能做到業務、技術、團隊三者對齊(康威定律再次起作用)。四色建模、事件風暴等方法都能有效地實現領域驅動設計，從而建立起良好的領域模型及服務邊界。
3. 事件驅動架構
使用異步的事件機制實現服務之間的通信。對于運行時間比較長、甚至本質上不可能立即完成的操作(例如涉及人工操作)，使用異步通信是合理的選擇。即便不考慮響應的實時性，事件驅動的架構還表達了領域模型之間的松散耦合關系：跨領域的協作以事件而非方法調用的形式來表達，系統追求最終一致性而非強一致性。這一結構準確地映射了真實世界中多支相關但獨立的團隊之間的協作關系，避免了過度依賴其他服務的響應速度或可靠性等服務質量指標，使服務真正具有技術上的獨立性。
在設計系統時，借助事件風暴方法，可以通過領域事件識別出聚合根，進而劃分微服務的限界上下文。當出現跨多個聚合根的事件時，可以很自然地將其實現為異步的領域事件，從而獲得與領域設計高度吻合的實現。
在實現事件驅動的架構時，當然可以沿用傳統的SOA架構中的消息中間件。但由于微服務架構中，業務邏輯都存在于各個服務內部，沒有龐大臃腫的ESB(稍后我們還會詳談這個問題)，因此消息機制也不需要強大的服務編排(orchestration)能力。RabbitMQ這樣標準的消息代理當然很好，也有很多系統(例如Bahmni)采用更簡單的做法：領域事件發生時，以ATOM格式發布;關心特定領域事件的其他領域模型則訂閱特定的ATOM feed主題。這種基于HTTP的事件傳播方式最大的好處就是簡單，幾乎不需要增加新的軟件就可以實現。不過這個方案在處理低延遲的場景時表現不佳。
4. 公共網關
微服務提供的API粒度與客戶端的需求不同，所以客戶端一個請求經常需要多個服務;服務端和客戶端之間可能需要通信協議轉換;不同的客戶端對數據的需求不同，例如瀏覽器客戶端需要的信息可能多于移動客戶端;服務的終端信息(主機+端口)可能變化;不同數據片可能由不同的服務終端來提供——以上這些因素都指出：有必要對服務做一層門面封裝，提供API網關作為所有服務使用者的單一入口點。
API網關處理請求的方式有兩種：一種是直接代理/路由給合適的服務;另一種是由一個請求扇出/分發給多個服務。API網關可能針對不同客戶端提供不同的API，可能包含針對客戶端的適配代碼。橫切需求(例如安全)也可能在API網關實現。
當服務數量變多、API網關變大以后，維護一個通用的API網關會增加API網關層的復雜度，導致一個獨立的“API團隊”出現，協調和溝通的工作量加大。這時可以考慮引入公共網關的一個變體：為特定前端設計的后端(Backend For Frontend，BFF)，即為每個前端應用提供一個單獨的API網關，使對齊業務的一體化團隊能夠拉通前后端開發、而不必等待“API團隊”完成他們的backlog。
API網關可以實現為一個獨立的服務端應用，其代價則是增加一層復雜度(和出錯的可能性)。為了降低這一代價，可以考慮用Zuul等工具來實現API網關。
5. 微服務SOA拓撲
與傳統的SOA架構相比，所謂“微服務”最大的特點可能就在于沒有一個重量級的ESB。重量級的ESB有其歷史原因。在2000年代業界剛開始采用SOA時，很多企業盡管把業務系統包裝成了web服務，但IT團隊的組織結構并沒有發生改變，仍然是由一組人集中式地掌管整個業務流程——只不過系統集成的方式不再是直接的方法調用，而是服務編排(orchestration)。原本存在于集成代碼中的復雜邏輯，現在被轉移到了ESB中。而這個“ESB團隊”成了IT交付的瓶頸：不論發布事件的服務還是消費事件的服務、或是編排邏輯本身的改變，與事件相關的變更都需要通過ESB團隊。這個團隊的backlog堆積起來，使得每個服務、每個應用都無法提供快速響應。
微服務架構更重視服務與業務的對齊。貝索斯所說的“兩個pizza的團隊”不僅負責一個IT系統的交付，而且要負責用這個IT系統來支撐一個業務的成功。為了做到單個服務能夠獨立開發、獨立部署、獨立運行，這支團隊應該能夠在很大程度上掌控自己的進度，而不依賴于一個集中式技術團隊的進度。因此微服務應該通過服務注冊與發現機制獲得自己需要的依賴服務、自己判斷是否要直接調用或訂閱依賴服務的事件，每個服務包含與其業務對應的復雜度，而不是把整個系統的復雜度集中在ESB和編排邏輯上。整個系統的架構(以及團隊的架構)應該呈現為若干個端到端拉通的、與業務對齊的縱切服務，而不是一個橫切的大塊(ESB)覆蓋所有業務。
三、小結
為了激活企業線下資源、打造行業線上生態，IT需要一套有效的服務API和架構治理方法。首先從領域驅動設計入手，劃分出合理的限界上下文和服務邊界，然后用異步消息機制來描述領域事件。設計好的服務通過API網關或BFF暴露給前端應用，把依賴關系和集成邏輯約束在與業務對齊的一體化團隊內部。在整個服務架構的設計中，需要保持對開發者體驗的關注。順暢地將企業資源服務化，這是企業數字化旅程的第二步。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
