本书首先回顾系统集成及服务的历史，对其核心概念和核心思想进行重新阐述；然后从基本概念、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社交媒体