现代API: 通往架构师之门
正版全新
￥ 51.02 7.5折 ￥ 68 全新
库存3件
上海浦东
认证卖家担保交易快速发货售后保障
作者李泉
出版社清华大学出版社
ISBN9787302505693
出版时间2018-08
装帧其他
开本16开
纸张胶版纸
定价68元
货号1860030
上书时间2023-10-09
- 在售商品 暂无
- 平均发货时间 19小时
- 好评率 暂无
商品详情
- 品相描述：全新
- 商品描述
-
【书 名】 现代API: 通往架构师之门
【书 号】 9787302505693
【出 版 社】 清华大学出版社
【作 者】 李泉
【出版日期】 2018-08-01
【版 次】 1
【开 本】 16开
【定 价】 68.00元
【编辑推荐】
汇集20年系统集成和API项目实战经验，软件开发人员成为架构师的必读指南
【内容简介】
本书首先回顾系统集成及服务的历史，对其核心概念和核心思想进行重新阐述；然后从基本概念、REST架构、生命周期、具体实施、*实践、业务影响和技术前瞻等方面对API进行全方位的介绍；*后是作者对如何做一个好的架构师的感悟与建议。贯穿全书的是作者在近20年里，为北美18个行业里的50多家大型公司进行系统集成及API项目设计和实施积累下来的实战案例。
本书为有志于成为系统集成和API架构师的程序员提供了一条学习和提高的路线图，适合程序开发人员及管理人员阅读和参考。
【目录】
第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社交媒体
【文摘】
第1章概述
在软件行业里,架构师们的头上仿佛都带有光环。他们往往对复杂的问题举重若轻。几乎每一个年轻的程序员都希望有朝一日自己也能成为一名经验丰富的架构师,领导着一个开发团队、解决着世界上*复杂的软件架构设计和实施的问题。
然而,一名成功的架构师到底学习了哪些东西、又经历了怎样的历练，似乎没有人讲解过；大学里从来不曾开设过相应的课程,更没有人能够提供一张“课程表”；市面上的关于架构的图书大多或偏重于讲授抽象的设计原则，或偏重于对设计思想的感悟。读者如果没有亲身经历过具体的项目案例，抽象的设计原则缺乏系统的应用指导和可执行性，而感悟只有在读者亲自做过之后才有可能产生共鸣。那些缺乏经验的新人该怎么办呢？他们是多么希望有一张通向架构师的路线图啊！
1.1什么是架构和架构师
万事开头难,文章开篇难！为了建立一个大家理解相同、不产生歧义的沟通基础，我们必须从两个*基本的概念入手。
首先，*重要的概念就是架构。按照维基百科的说法https：//en.wikipedia.org/wiki/Software_architecture： 软件架构是指软件系统在高层次上的结构、创建此类结构的指导原则，以及这些结构的相关文档。这些结构可以用来推断和评价待建的软件系统。每一个结构包含软件的组成部分及其相互之间的关系，以及组成部分和相互关系的属性。一个软件系统的架构类似于建筑的架构。其次，就是架构师的概念及分类。还是按照维基百科的说法https：//en.wikipedia.org/wiki/Software_architect： 软件架构师的工作就是进行高层次上的设计方案选择、制定相关的技术标准，包括软件编码标准，并确定所使用的软件工具和平台。尽管有人将架构师的种类分得很细https：//blog.prabasiva.com/2008/08/21/differenttypesofarchitects/，实际*常见的架构师分为两种。〖=1〗 企业架构师（Enterprise Architect）： 研究的对象是解决方案架构师在实施工作过程中所使用的方法，为后者解决具体的业务问题提供架构设计以及实施的具体步骤和方法指导。
解决方案架构师（Solution Architect）： 实际承担解决企业业务问题的任务。有可能需要使用企业架构师所提供的架构设计以及实施的具体步骤和方法指导。〖=2〗换句话说，企业架构师解决的是IT问题，而解决方案架构师解决的是业务问题。贯穿本书所指的架构师是后一种，即解决方案架构师。不仅如此，本书面向的是那些解决方案涉及多个功能系统的使用、架构原则和思想具有横跨企业的指导意义的架构师。
1.2这本书是为谁写的
本书针对的读者群包括希望成为解决方案架构师的程序员、IT咨询师，希望通过与同行进行交流而得到提高的架构师，还有希望了解如何能够让自己的部门有效地应对不断变化的企业业务要求的各级IT 领导。
一名IT从业人员可能正处在下面列出的一种情形之中：
1) 刚刚走出大学的校门、参加工作。在计算机系里已经学会了一门或几门编程语言（如Java、C#、Python，等等），以及数据结构和算法，对后台数据库、网站架构甚至SOAP Webservices都有初步的了解，并且可以很熟练地进行编程来解决别人交给的非常具体的问题。但是如果面对类似本章1.3节中所描述的那几个实战例子就不知从何下手了。
2) 从事软件开发工作3～5年，十分胜任小型或局部问题的分析、方案设计和具体实施。然而面对规模稍大、更加复杂并涉及多个系统的业务问题的设计任务时会感到力不从心，不知道从何下手，不知道应该采用什么样的原则以及设计和实施步骤，也不知道应该使用何种工具。
3) 作为一名具有2～3年实际经验的架构师，已经参与和主持了几个系统集成项目的设计和实施工作，但对为什么采用某个设计方案、其优点和缺点的评估却说不出个所以然来，因此无法在下一个项目的工作中信心十足地再次采用类似的方案。
4) 从事架构师的工作已有5～10年，能够深入了解具体设计方案背后的来龙去脉，以及设计方案的优点、缺点甚至相应的补救措施。然而，面对一个复杂项目各方面的利益相关人（如项目出资方、业务分析人员、其他设计人员、开发团队、项目经理、合作伙伴，等等），深深地感到将项目设计的思想和方案优缺点论述清楚并得到方方面面的支持是一件十分困难的事情。即便是开发团队内部的技术细节的沟通和统一也不是那么容易。
5) 作为一名具备多年实践经验的企业CIO，面对行业内竞争、行业外颠覆的压力，以及企业业务对IT能力的要求与IT部门实际交付能力之间日益增大的差距（如图11所示）深感忧虑（其背后的直接原因包括移动设备、云计算、社交网络、大数据、物联网等的广泛和深入的使用），并苦苦探索可从IT技术和企业组织结构的不同角度对这个日益严重的问题做出有效的反应。
图11数字时代的压力造成了IT部门“欠债”越来越多
1.3为什么写作此书
在从事软件服务工作的近20年中，作者亲身经历了北美18个行业、50多个客户的大型项目，其中还包括两三个完全失败的项目。客户中的绝大多数是财富500强的公司，有些甚至是50强。
我们先来粗略地感受一下这些项目。〖=1〗 某跨国石油公司的能源交易部门于2002年希望建立一个全球范围的能源产品 （包括石油、天然气、电力、污染排放指标等）交易结算和风险评估平台，能源产品可在全世界各地进行交易，而新的交易实时地与交易伙伴进行结算，本部门所持有的能源产品组合的细节及其系统风险被实时地更新。如果交易的一方或双方隶属于某个母公司，母公司本身所持有的能源产品组合的细节及其系统风险也被实时地更新，任何过度风险的情形都会被及时预警。
美国某著名的航空快递公司在2005年寻找一个高效、耐用的消息（message）交换平台，能够每天交换86000万条在邮件递送过程中由每一个处理中心的进出扫描而产生的消息。而这些消息在全天的任何时间、在世界上的任何地方不断地产生着。在此平台上需要进一步构建供广大消费者使用的邮件跟踪服务。到2010年，这个平台的消息总处理能力达到了每天50亿条。而且以不同名称独立运营的同一个母公司下的所有分公司使用快递服务的总量，以及使用的模式可以被累加出来，为下一年针对不同母公司的大客户进行更好的服务定价提供可靠的基础。
美国某知名零售连锁店有800多家店面，销售包括衣服、家电、日用品等在内的上万种商品。每个星期，总店都会在不同的商品上推出各种不同的促销折扣以及减价券，而有些时候这些促销折扣和减价券的有效期只有某一天中的几个小时。促销折扣及减价券的推出上线必须经过特定权限的批准，在此过程中完全不允许出现停机现象。
美国某玩具公司拥有多个世界上*著名的玩具品牌。在2012年引入了产品生命周期管理PLM（Product Lifecycle Management）的软件系统后，PLM成为玩具产品设计、制造、市场开发、销售、服务等几乎所有的企业职能部门共同需要的平台。然而，由于历史的原因，这些职能部门目前使用的外购和自己开发的应用系统超过了50个，加上这些职能部门分布在北美、欧洲、中国、东南亚等多个地区或国家，实际上根本不可能让这些职能部门全面放弃已经使用了十几年甚至几十年的、他们所熟知的系统。然而，由于所有围绕玩具产品的各类职能的数据已经全部转移到PLM平台上，如何在保证这些职能部门继续使用现有系统的同时，能够从新的PLM平台上及时、有效地获得不断更新的相关数据？
美国某著名的二手车销售连锁店在美国和加拿大拥有近千家店面，销售经过重新认证的二手车。总店拥有自己的IT系统，而每一个分店除了可以调用总店的IT系统外，还有一套本地备份，以便本地系统在与总店IT系统失联的情况下仍能应付日常工作。连锁店在2010年面临的挑战之一就是，每当总店推出一个新的系统部署时，比如升级和更新，甚至仅仅只是网页上的横幅图标按某个节日进行临时的更换，如何能够*有效地部署到所有近千个店面的本地IT系统中，同时了解哪些店面的部署出现了错误并进行妥善的处理。这是一个相当具有挑战性的问题我们*终的多店面部署解决方案被称为StoreinaBox。。〖=2〗仔细研究一下上面这几个实战案例，我们也许会在某个局部发现书本上学过的N层网站架构或者某个设计模式（Design Pattern），但组合起来造成的问题之复杂，是我们从前不可想象的。
环顾软件以外的其他行业，对过去的相关案例进行深入的分析和总结，无论对个人还是团队来说，都是非常有效的学习手段。在商学院、医学院、法学院、军事学院和体育学院的课程安排里，案例的分析是学习的内容和过程中*重要的、也是*引人入胜的部分。通过例子来学习、先模仿再深入理解是*有效的学习方法之一。在作者的软件咨询服务工作过程中，客户*享受的部分就是“听故事”，然而作者却没有在美国和中国任何一所高校的计算机系网站上公布的授课内容中找到软件项目设计和实施的案例。
除技术因素外，作者在主持项目设计和实施的过程中，对如何与客户、合作伙伴，以及自身领导的开发团队成员进行架构设计指导思想的沟通与说服工作，也积累了相当的感悟。
以上两点促使作者下定决心，抛砖引玉，力图提供一条由程序员到架构师的路线图，并结合实战的架构设计案例来对抽象的设计原则进行展开说明，为希望成为架构师的程序员们的学习和实践过程进行具体的指导。本书将采取理论阐述和动手开发相结合的方式，以保证学习和能力提高的质量。
1.4通往架构师之路的路线图
针对上面列举的通往架构师的道路上的不同阶段，本书拟引入如下的路线图。
1) 起始于相互独立的系统，首先讨论如何进行系统集成（第2章~第4章）。具体内容包括系统之间进行集成时常见的相互作用模式、被集成系统的功能分类，等等。这一部分的内容已有大量的书籍进行了各种深入的阐述。然而在实际项目中遇到的许多关于设计方案选择的把握并未见有论述；对系统集成设计的体会和设计思想上的领悟也未见有太多公开的发表。因此，希望对系统集成和服务架构有一定经验和体会的读者也不要轻易跳过这几章。作者真心地期待你使用前言末尾列出的电邮地址分享案例、体会和领悟，抒发情怀。
2) 在通过集成、系统与系统之间的连接初见成效之后，引入服务的概念（第5章），并对围绕服务的项目实施具体工作内容进行了解（第6章、第7章）。服务概念的出现虽然已有至少15年的历史，但在绝大多数实际的项目实施过程中服务常常沦为“点对点”实施的一种新的连接机制，而整个架构思想换汤不换药。其结果是，根本性的技术问题依然存在，一个也没有彻底解决。
3) 在积累了一定的系统集成和服务项目的经验后，第8章承上启下，以作者在近20年的实践中对系统集成和服务的方法以及在技术层面和IT组织结构层面上的局限性的总结和思考，引入现代API的概念，并与围绕服务和系统集成项目的实施进行对比，从而对*新的、围绕API的架构理念有一个初步的认识。
4) 了解围绕API进行解决方案开发工作的具体内容，并对具体实施方法背后的深层思想进行梳理（第9章、第10章）。不论采用什么样的API的设计和开发工具，这个过程大致相同： 从API的提供方看，涉及API开发的生命周期中的各种活动；而从API的使用方看，则涉及如何发现并正确使用API。
5) 深入了解API与微服务（以及服务）之间的关系（第11章）。这个问题常常被客户问到，并且具有理论和实践上的重大意义。
6) 深入了解API的部署方式，特别是正在兴起的云端部署方式（第12章）。云端部署为API以及集成应用的目标环境提供了一种新的选择。API架构师的目标是采用完全不依赖于目标环境（比如本地/数据中心、云端的虚拟机、云端带有负载平衡器、集群等相关设施的部署环境，以及以上各种类型的混合体，等等）的基础代码，而是通过因目标环境而不同的配置上的变化来实现不同环境下的部署。
7) 在上述学习和提高的过程中，不断积累*佳实践的经验和教训（第13章），了解新的架构思想对企业业务发展的影响（第14章），加深在这方面的认识。
如果要打个比方，上面提议的路线图有点儿类似于一个从士兵到将军的计划。士兵的责任在于提高体能，掌握军事技能和武器装备;中层军官的责任在于熟悉自己权限以内的兵力调动，指挥战斗和局部的战役；而高级将领的责任则在于熟知军
相关推荐
— 没有更多了 —
以下为对购买帮助不大的评价