本書首先回顧系統集成及服務的歷史，對其核心概念和核心思想進行重新闡述；然后從基本概念、REST架構、生命周期、具體實施、*實踐、業務影響和技術前瞻等方面對API進行全方位的介紹；*后是作者對如何做一個好的架構師的感悟與建議。貫穿全書的是作者在近20年里，為北美18個行業里的50多家大型公司進行系統集成及API項目設計和實施積累下來的實戰案例。
本書為有志于成為系統集成和API架構師的程序員提供了一條學習和提高的路線圖，適合程序開發人員及管理人員閱讀和參考。
匯集20年系統集成和API項目實戰經驗，軟件開發人員成為架構師的必讀指南
For Robin, Lindsey & Laura
從2018年開始，絕大多數的中國企業都會把數字化轉型作為企業核心戰略；2020年，中國GDP的20%將來自數字化轉型的增加值。在新的時代，企業應對數字化轉型的速度，以及創造數字化產品、服務和體驗的能力，不僅將決定其未來的發展，還將決定其未來的生存。這不是一件企業想不想做的事情，而是不得不做的事情。即便你已經是行業領軍者，依然有可能被來自行業外部的顛覆者改變游戲規則而走向衰敗。這樣的例子比比皆是。
企業數字化轉型成功的關鍵不僅僅在于數據有多少，更重要的是應用數據和信息的能力。而能夠正確應用數據和信息的前提，是能夠將原始數據以合適的形式和語境，在合適的時間呈現給合適的應用。這就是系統集成需求的根本由來。
為了應對企業數字化轉型過程中遇到的數據格式不統一、內容不一致，調用方式五花八門，系統豎井林立、孤島叢生，以及內外部協作難、創新慢、流程長等一系列的挑戰，勢必要有一種新型的技術架構來滿足企業業務越來越快、越來越敏捷的要求。
REST API并不是一項新的IT技術，但本書賦予了基于API開發、集成的新的應用場景。其中對于API的三層架構的闡述尤為獨到： 以系統資源API打通系統孤島，發現并呈現統一格式的數據資產；以協同流程API根據業務邏輯對數據資源進行組合、提煉，實現功能協作和流程重組；最終以用戶體驗API用于業務應用的快速、自主自助式的開發，推動能力輸出和業務創新。
基于現代API的架構思路，企業可以更好、更快地將內部資產理清和重組，進而對業務流程、現有資源深挖和商業模式重新進行思考和創新。作者在這方面列舉了大量親身經歷的案例，并對其中深層的架構思想和實施步驟細節、最佳實踐、相應的組織結構安排等都進行了較為系統的論述，既有理論性，又有可操作性。白山云科技公司在業務工作中同樣遇到過大量類似的客戶案例。僅舉一例： 為建設統一的船舶產業鏈云平臺，中國某大型船舶物資供應集團公司的10多個業務廠商進行各自的子系統建設。在每一個廠商依據自身的標準進行了系統建設之后，發現各子系統之間的通信較為困難。如果以ESB來實現各業務系統交互，實施過程中各開發廠商就需要大幅改造自身系統匹配ESB的Web Service服務，這就會存在影響業務系統穩定運行的風險。另外，各業務系統通過ESB進行交互，相互之間信息傳輸無法直觀展現和實時掌控，出現問題時排查比較困難；也無法將平臺中的業務內容以標準化的方式對外界開放以及進一步建設完善的業務資源生態系統。
為保障快速、穩定地實現信息交換和資源共享，白山云科技公司參與主持的這個項目中的各業務系統將已開發的各種格式的接口統一轉換成REST API，并以REST API的方式實現系統敏捷交互，快速響應業務要求的變化；真正在API上線、安全、監控、分析、編輯、運行、權限控制、流量控制、告警、下線等流程上實現了API的完整的生命周期管理。基于這樣的敏捷集成的云平臺，今后可以將各種新業務和應用進行快速編排、測試并上線；還可以將所有封裝好的系統API和流程API呈現在API市場中，對企業內外進行能力開放，供上下游合作伙伴調取、計費，實現數字化推進，形成全新的船舶生態和API經濟體。
各方面的數據顯示，北美的企業在系統集成、資源共享，進而持續創新和數字化轉型這一塊的需求價值在千億美元的量級。國內企業相同的需求也是巨大的，隨著企業持續創新和數字化轉型的擴大和深入，這種需求只會加速增長。然而，盡管需求和市場巨大，白山云科技公司在開發和銷售自己特有的系統集成和API平臺的過程中深刻地體會到，滿足這方面要求的人才尤其是領軍人物極其缺少；相關的技術資料、信息、案例也十分匱乏。作者的這本書理論和實踐并重，恰好填補了國內IT圖書市場在這方面的空白。
作者真誠地向有志成為企業級IT解決方案架構師并推動企業持續創新和數字化轉型的綜合型IT人才推薦這本書。
趙鵬（Eddie Zhao）[]白山云科技有限公司產品副總裁〖〗2018年4月26日于北京
2018年5月2日，在世界范圍內(包括在中國)享有盛譽的客戶關系管理 (CRM) 軟件供應商Salesforce以65億美元的價格完成了對系統集成和API管理平臺供應商MuleSoft的收購，其收購價格達到了MuleSoft股價溢價36%以上，為2000年.COM泡沫以來收購溢價的最高。關于Salesforce收購MuleSoft的具體原因，在網上可以看到各種各樣的分析。有一點是確定的： 資本市場愿意為能夠有效解決系統和數據整合問題的方案、平臺和技術付出高昂的代價，并期待豐厚的回報。
盡管很多人都認為系統集成是一個老話題，REST API也是耳熟能詳的技術，沒什么新東西好談了，然而，很多財富500強公司（甚至50強公司）在一二十年后依然在尋找好的系統集成平臺和集成框架；大多數使用REST API的技術人員卻對REST的架構風格以及圍繞REST API的愿景知之甚少。這些都從一個側面反映出，我們對圍繞系統集成和API的基本概念和基本原則并不十分清楚，而且常常不能夠準確清晰地進行表述。
寫作本書的想法至少有兩三年的時間了。但在很長的一段時間里，作者自覺很難做到幾句話就清晰地回答書稿出來之后必然要面對的一個問題： 你到底想說什么？是的，一本書沒有明確的重點就很難具備貫穿全書的一致性，不僅內容會零散，也沒有辦法吸引來所希望針對的讀者群。
在細細地梳理各種思緒之后，作者發現了兩條主線： 一條是關于事的，另一條是關于人的。
在事這條主線上，作者在過去近20年里，作為MuleSoft和TIBCO兩家軟件公司的資深服務解決方案架構師主持和參與了北美18個行業、50多個客戶的大型系統集成、面向服務架構和現代API項目。客戶中的絕大多數是財富500強，甚至是50強的企業。中間經歷了相關的IT技術翻天覆地的演變和發展，積累了很多的體會和感悟。
在人這條主線上，在近20年的時間里，作者不僅在項目上經常地與客戶及合作伙伴進行技術方面的討論，還為公司進行了200多次的解決方案架構師人選的技術面試，并在公司里帶徒弟，為年輕的架構師們作指導（Mentor）。這樣的經歷讓作者有機會對架構師的學習和提高過程有了一個同時具備空間維度（不同的人）和時間維度（同一個人的成長經歷）的觀察和思考，希望從中能夠總結出一份架構師的學習路線圖。
在技術的主題中，本書的重點是現代API。從來沒有接觸過現代API的讀者可以用任何瀏覽器去訪問https：//www.pokeapi.co/，應該看到類似下面的口袋妖怪（Pokemon）信息內容： {
"id"： 1,
"name"： "bulbasaur",
"base_experience"： 64,
"height"： 7,
"is_default"： true,
"order"： 1,
"weight"： 69,
"abilities"： \[
{
"is_hidden"： true,
"slot"： 3,
"ability"： {
"name"： "chlorophyll",
"url"： "http：//pokeapi.co/api/v2/ability/34/"
}
}
\],
……
}簡單地講，現代API就是用最普遍的HTTP(s)的通信方式對世界上的任何（信息）資源進行調用。如果你對面向服務架構（SOA）和SOAP Webservices十分熟悉，而對為什么會出現REST API心存疑惑；或者你已經在使用REST API，卻無法用不超過三句話來說明服務與API之間在架構思想上的區別，那么這本書就是為你準備的。從大家都熟悉的SOAP Webservices到REST API，這背后的架構理念、項目實施方式和相應的企業組織結構以及API對企業業務深遠的影響，還有一個開發員如何在這個學習和實踐的過程中成長為一名合格的架構師，這些就是本書想要說清楚的話題。
如果在這兩條主線中再找出一條共同的主線，那應該就是分享。關于架構和服務的話題在市面上已經有太多的書了，而關于現代API的書在北美圖書市場上也已開始出現。但是現實往往是很殘酷的： 既然人人都知道點對點集成做法的害處，那為什么來自世界著名的軟件公司和著名的IT咨詢公司的API架構師們在一個客戶項目上花掉幾千萬美元服務經費（不包括軟件授權的費用）后，最終的結果還是點對點集成的失敗呢？為什么在項目設計的過程中說服別人那么難，而項目結束時能夠承認錯誤、總結經驗教訓也那么難呢？任何事情都是這樣，說到是一回事，能做到則是另一回事。理論要經過實踐的摸索，包括經歷失敗，才能轉化為成功的結果和經驗。
現代API是當前很多熱門技術和企業戰略的使能者。云計算、數據共享、應用網絡、企業數字轉型與創新、智能城市、物聯網，等等，在這些熱門話題中都能找到API的身影。一個現代API架構師的最高境界就是在深入理解API設計和開發工作的技術細節之上，對API戰略在企業轉型和創新中的作用具有深刻的洞察力，并對企業業務的提升產生真正的影響。
對于希望自己開發出自用的或是商用的各種API工具的公司和架構師來說，本書，尤其是第9章和第10章的內容，也具有重要的借鑒意義。
作者期待與讀者一起探索，共同提高！歡迎讀者與作者進行技術及各方面的交流并提供意見和反饋。請發郵件至charlesquanli@gmail.com。在這個學習過程中的樂趣和成就感才真正是妙不可言！
李泉〖〗2018年5月18日于美國休斯敦
第1章概述
1.1什么是架構和架構師
1.2這本書是為誰寫的
1.3為什么寫作此書
1.4通往架構師之路的路線圖
1.5架構師應該具備的素質
1.6對架構師的學習和培養過程的幾點建議
1.7本書的主要內容
1.8總結
第1部分基礎篇
第2章重新看待系統集成
2.1系統集成歷史的快速回放
2.2到底什么是系統集成
2.2.1系統集成之信息更新
2.2.2系統集成之信息組合
2.2.3系統集成之連鎖行動
2.3系統集成的技術組成部分
2.3.1BUS高速公路
2.3.2連接器高速公路的進出口
2.3.3CDM高速公路運輸的集裝箱
2.3.4數據轉換運輸過程中的貨物處理
2.4系統集成應用的考慮
2.4.1系統集成的過程中到底要完成什么任務
2.4.2如何保證系統集成過程中數據傳遞的可靠性
2.4.3如何使用消息服務器
2.5實戰： PLM數據與現有系統的集成
2.5.1項目背景
2.5.2業務痛點
2.5.3技術難點
2.5.4解決方案及經驗教訓
2.6總結
第3章系統之間相互作用的模式
3.1系統集成模式簡介
3.2系統集成模式中幾個最重要的概念
3.2.1主題與隊列在消息傳遞中的區別
3.2.2消息服務器所使用的儲存轉送
3.2.3消息服務器的容錯和高可用性
3.2.4分級式事件驅動架構及其實際應用
3.3系統集成模式的實戰應用和分析
3.3.1消息的順序處理
3.3.2持久訂閱如何實現
3.3.3命令類消息的應用
3.3.4事件消息的使用
3.3.5回復地址的使用
3.3.6消息傳遞搭橋的使用
3.3.7消息信封的使用
3.4總結
第4章常見的參與集成的功能系統
4.1功能系統與集成基礎設施的連接
4.2常見功能系統的功能和類型
4.3總結
第5章究竟什么是服務
5.1什么是服務
5.2是誰在推動服務的重復使用
5.3服務的操作
5.4服務的界面
5.5服務操作的粒度
5.6服務的組合SOA
5.7實戰： 數據
5.7.1項目背景
5.7.2業務痛點
5.7.3技術難點
5.7.4解決方案及經驗教訓
5.8總結
第6章系統集成項目的實施步驟
6.1系統集成與服務項目概述
6.2系統集成與服務項目的具體實施步驟
6.3設計和開發階段
6.3.1搜集項目業務功能要求
6.3.2架構設計
6.3.3細節設計
6.3.4代碼編寫和單元測試
6.3.5集成測試
6.4測試和驗收階段
6.4.1質量保證(QA)部署
6.4.2質量保證(QA)測試
6.4.3用戶驗收(UA)部署
6.4.4用戶驗收測試(UAT)
6.4.5(可選項)操作驗收測試(OAT)
6.5運維、培訓和交付階段
6.5.1生產環境部署
6.5.2試運行
6.5.3培訓及文檔提交
6.5.4項目驗收
6.6總結第7章集成項目與公共服務
7.1公共服務的具體內容
7.1.1日志服務
7.1.2出錯處理服務
7.1.3ID映射服務
7.1.4順序處理服務
7.1.5系統及應用監控服務
7.1.6應用、服務、API的分析服務
7.2業務項目的項目模板及其與公共服務的互動
7.3總結
第8章SOA在實施中的局限性
8.1SOA在具體實施中的做法
8.1.1SOA的設計原則
8.1.2SOA績優中心
8.2深挖SOA的初衷
8.3SOA的適用范圍和局限性
8.4總結
第2部分正篇現代API、應用互聯網
第9章現代API的引入、應用互聯網
9.1什么是（現代）API
9.1.1REST架構的特點
9.1.2REST架構的特點在API中的具體應用
9.2（現代）API流行背后的原因
9.2.1API和云平臺的普及
9.2.2API與企業數字化轉型、應用互聯網以及API經濟
9.3API的平臺和工具有待進一步地統一和標準化
9.4一個REST API的結構
9.5對API的認識不是一蹴而就的
9.6動手開發API先嘗為快
9.7總結第10章圍繞API的開發工作
10.1API的生命周期
10.1.1API的設計生命周期
10.1.2API的運維生命周期
10.2API的調用者
10.3API項目中的人員和流程
10.3.1什么是使能中心
10.3.2圍繞使能中心的不同角色
10.3.3使能中心與績優中心的區別
10.3.4建立使能中心的具體步驟
10.3.5建立使能中心的好處
10.4總結
第11章API與微服務
11.1什么是微服務
11.2微服務與服務的關系
11.3微服務與API的關系
11.4總結
第12章API與云計算
12.1云計算需求的由來
12.2云計算對API技術的影響
12.2.1云計算的平臺能為你的API和應用提供多少服務
12.2.2現有系統之間的連接是否受到影響
12.2.3是否需要增加安全措施
12.2.4如何將API負責對內和對外的部分分開
12.3實戰： 全云和云本地混合型的API平臺
12.3.1項目1背景
12.3.2項目1云平臺的架構
12.3.3項目2背景
12.3.4項目2混合型平臺的架構
12.4總結第13章最佳實踐的經驗
13.1關于系統集成的最佳實踐
13.1.1不要以數據復制的思考方式設計系統集成
13.1.2盡量避免使用批處理文件的方式
13.1.3對消息服務器運行的認識
13.1.4使用SEDA的架構模式來提高系統集成整體設計
的可靠性
13.1.5對容錯、負載平衡和高可用性的考慮
13.1.6對災難恢復設置的考慮
13.1.7接收JMS消息時的消息確認方式對消息處理
可靠性的影響
13.2關于API的最佳實踐
13.2.1在設計API的過程中使用資源的字眼，而不要
使用數據
13.2.2不要使用API的概念和方式來做系統集成
13.2.3API還是連接器
13.2.4API實施中的出錯處理
13.2.5API的URI的每一個部分都應該是名詞，
而不是動詞
13.2.6API的版本管理
13.3關于架構設計的最佳實踐
13.3.1不要使用UML的時序圖來編寫系統集成的
用例文件
13.3.2注意區分設計中功能方面和非功能方面的要求
13.3.3不要在沒有系統性能指標要求的情況下對系統
進行性能的評價和測試
13.3.4數據驗證邏輯與數據的關系
13.3.5API、服務和集成中均不保留狀態
13.4總結
第14章圍繞API的展望
14.1關于企業的IT欠債
14.2利用API產生新的業務創新和數字化轉型
14.2.1優步（Uber）的創新
14.2.2郵局的數字化轉型
14.2.3電力公司旨在提高零售用電顧客滿意度
的數字化轉型
14.2.4玩具公司旨在減少貨運差錯和加快貨款回收
的數字化轉型
14.3利用API產生應用互聯網和API經濟
14.4總結
第3部分閑篇感悟與隨想
第15章架構師的人文情懷
15.1關于學習過程中的三個境界
15.2架構師所要具備的硬實力
15.3架構師所要具備的軟實力
15.3.1時刻分清目的和手段
15.3.2處處講究形式邏輯
15.3.3強調利用抽象思維的能力
15.3.4表達和交流要看對象
15.3.5堅持原則，但也要知道妥協
15.3.6知之為知之，不知為不知
15.4架構師所處的大環境
15.4.1架構師的職業規劃
15.4.2軟件工程問題與業務問題的分離
15.4.3高校計算機軟件課程設置與現實對架構師要求的
匹配問題
15.5總結
附錄A關于實踐
A.1搭建MuleSoft的開發和運行環境開源版
A.1.1開發環境
A.1.2運行環境
A.2安裝Apache ActiveMQ消息服務器開源版附錄B集成中常遇到的功能系統
B.1業務流程管理系統（Business Process Management，BPM）
B.2復雜事件處理（CEP）
B.3云端系統
B.4客戶關系管理系統（CRM）
B.5數據庫系統（Relational、Object、NoSQL）
B.6電子內容管理（ECM）
B.7電子商務（eCommerce）
B.8電子數據交換（EDI）
B.9企業資源規劃（ERP）
B.10人力資本管理
B.11行業標準
B.12IT開發和運行工具
B.13IT基礎設施管理
B.14傳統系統改造
B.15主數據管理
B.16消息傳遞服務器
B.17通信協議
B.18社交媒體
新書資訊