作者：李泉
出版社：清华大学出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
现代API:通往架构师之门试读：
前言
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）信息内容：
简单地讲，现代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 什么是架构和架构师
万事开头难，文章开篇难！为了建立一个大家理解相同、不产生歧义的沟通基础，我们必须从两个最基本的概念入手。
首先，最重要的概念就是架构。按照维基百科的说法：
软件架构是指软件系统在高层次上的结构、创建此类结构的指导原则，以及这些结构的相关文档。这些结构可以用来推断和评价待建的软件系统。每一个结构包含软件的组成部分及其相互之间的关系，以及组成部分和相互关系的属性。一个软件系统的架构类似于建筑的架构。
其次，就是架构师的概念及分类。还是按照维基百科的说法：
软件架构师的工作就是进行高层次上的设计方案选择、制定相关的技术标准，包括软件编码标准，并确定所使用的软件工具和平台。
尽管有人将架构师的种类分得很细，实际最常见的架构师分为两种。
• 企业架构师（Enterprise Architect）：研究的对象是解决方案架构师在实施工作过程中所使用的方法，为后者解决具体的业务问题提供架构设计以及实施的具体步骤和方法指导。
• 解决方案架构师（Solution Architect）：实际承担解决企业业务问题的任务。有可能需要使用企业架构师所提供的架构设计以及实施的具体步骤和方法指导。
换句话说，企业架构师解决的是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部门实际交付能力之间日益增大的差距（如图1-1所示）深感忧虑（其背后的直接原因包括移动设备、云计算、社交网络、大数据、物联网等的广泛和深入的使用），并苦苦探索可从IT技术和企业组织结构的不同角度对这个日益严重的问题做出有效的反应。图1-1 数字时代的压力造成了IT部门“欠债”越来越多1.3 为什么写作此书
在从事软件服务工作的近20年中，作者亲身经历了北美18个行业、50多个客户的大型项目，其中还包括两三个完全失败的项目。客户中的绝大多数是财富500强的公司，有些甚至是50强。
我们先来粗略地感受一下这些项目。
• 某跨国石油公司的能源交易部门于2002年希望建立一个全球范围的能源产品（包括石油、天然气、电力、污染排放指标等）交易结算和风险评估平台，能源产品可在全世界各地进行交易，而新的交易实时地与交易伙伴进行结算，本部门所持有的能源产品组合的细节及其系统风险被实时地更新。如果交易的一方或双方隶属于某个母公司，母公司本身所持有的能源产品组合的细节及其系统风险也被实时地更新，任何过度风险的情形都会被及时预警。
• 美国某著名的航空快递公司在2005年寻找一个高效、耐用的消息（message）交换平台，能够每天交换86000万条在邮件递送过程中由每一个处理中心的进出扫描而产生的消息。而这些消息在全天的任何时间、在世界上的任何地方不断地产生着。在此平台上需要进一步构建供广大消费者使用的邮件跟踪服务。到2010年，这个平台的消息总处理能力达到了每天50亿条。而且以不同名称独立运营的同一个母公司下的所有分公司使用快递服务的总量，以及使用的模式可以被累加出来，为下一年针对不同母公司的大客户进行更好的服务定价提供可靠的基础。
• 美国某知名零售连锁店有800多家店面，销售包括衣服、家电、日用品等在内的上万种商品。每个星期，总店都会在不同的商品上推出各种不同的促销折扣以及减价券，而有些时候这些促销折扣和减价券的有效期只有某一天中的几个小时。促销折扣及减价券的推出上线必须经过特定权限的批准，在此过程中完全不允许出现停机现象。
• 美国某玩具公司拥有多个世界上最著名的玩具品牌。在2012年引入了产品生命周期管理PLM（Product Lifecycle Management）的软件系统后，PLM成为玩具产品设计、制造、市场开发、销售、服务等几乎所有的企业职能部门共同需要的平台。然而，由于历史的原因，这些职能部门目前使用的外购和自己开发的应用系统超过了50个，加上这些职能部门分布在北美、欧洲、中国、东南亚等多个地区或国家，实际上根本不可能让这些职能部门全面放弃已经使用了十几年甚至几十年的、他们所熟知的系统。然而，由于所有围绕玩具产品的各类职能的数据已经全部转移到PLM平台上，如何在保证这些职能部门继续使用现有系统的同时，能够从新的PLM平台上及时、有效地获得不断更新的相关数据？
• 美国某著名的二手车销售连锁店在美国和加拿大拥有近千家店面，销售经过重新认证的二手车。总店拥有自己的IT系统，而每一个分店除了可以调用总店的IT系统外，还有一套本地备份，以便本地系统在与总店IT系统失联的情况下仍能应付日常工作。连锁店在2010年面临的挑战之一就是，每当总店推出一个新的系统部署时，比如升级和更新，甚至仅仅只是网页上的横幅图标按某个节日进行临时的更换，如何能够最有效地部署到所有近千个店面的本地IT系统中，同时了解哪些店面的部署出现了错误并进行妥善的处理。这是一个相当具有挑战性的问题。
仔细研究一下上面这几个实战案例，我们也许会在某个局部发现书本上学过的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章），加深在这方面的认识。
如果要打个比方，上面提议的路线图有点儿类似于一个从士兵到将军的计划。士兵的责任在于提高体能，掌握军事技能和武器装备；中层军官的责任在于熟悉自己权限以内的兵力调动，指挥战斗和局部的战役；而高级将领的责任则在于熟知军事服务于政治，时刻牢记进行战争的最终目的，有能力指挥各兵种及各级军官并协调友军进行大规模的立体作战。1.5 架构师应该具备的素质
要想成为一名优秀的架构师，除了高超的计算机软件专业方面的知识以外，还必须具备一定的“软实力”。有些软实力看似十分简单和基本，但在具体的执行过程中常常被遗忘和忽略。而错误的发生往往就是因为人们忽略了最简单明了的一些基本原则。
• 永远把解决客户的业务需求放在第一位。IT技术是手段，不是目的。无论你掌握的IT技术有多先进、多“酷”，如果不能解决客户具体的业务问题，你掌握的技术就会被客户看成是一无是处。所以作者经常讲的一句话就是，“架构师别太把自己当回事儿”。
• 超强的逻辑性。这其中既包括分析问题的数理逻辑能力，也包括在阐述论点和设计思路过程中的一致性、连贯性和洞察力。
• 永远开放的头脑。倾听和认真分析各种意见，始终抱着一种将事情做到极致的决心。
• 广泛的知识面，对IT技术和业务知识有着同样浓厚的兴趣。如果对所要解决的业务问题漠不关心，是不可能完善地使问题得到解决的。
• 超强的学习能力，并学以致用。学习的内容包括IT技术、业务知识、管理知识、认知科学甚至心理学等人文方面的知识。
• 注重结果。无论开始和过程有多么华丽，只有结果的辉煌才是真正的成功。架构师工作的成功来自于项目的圆满完成、用户预期从项目成功中获得的价值得到实现。1.6 对架构师的学习和培养过程的几点建议
除了以上阐述的成为架构师的路线图，以及作为一名合格的架构师所应有的基本素质之外，作者对有志成为架构师的IT人士还有以下几点建议。
• 在学习过程的最开始，明确说出作为程序员或者初级架构师在工作中所面临的困惑，并记录下来。在今后学习的过程中，不时拿出这些困惑来再读一读，看看是不是有的困惑已经得到了解决；同时记录下新的困惑和问题。
• 在学习过程的最开始以及阶段性的开始，明确说出学习和实践试图达到的目标。这些目标必须是十分具体的，能在事后客观地进行衡量看是否达到了，并根据不断提高的现有认识水平提出更高层次的目标。
• 针对个人的具体情况，按照本书的建议列出为了达到目标所要学习的相关内容，对上面建议的路线图进行个性化的丰富和完善。
• 下棋要找高手。和其他的架构师进行交流，尤其是在特定的设计原则和方法及其实际应用上进行交流，对于一个架构师的成长和提高十分有必要。而这个过程会很有收获，也可以是很快乐的。
• 要使用合适的工具。如果你也认为仅仅带上装有榔头、钳子和改锥的工具包是不可能建成摩天大厦的，那么你就肯定会同意，必定需要合适的、贯穿软件生命周期各个阶段的、成熟的软件工具，才有可能完成大型复杂系统的架构设计和具体实施。
学习、实践、总结、提高，这才是成为一名合格的架构师的必经之路。1.7 本书的主要内容
本书由3部分组成。
• 第1部分介绍系统集成架构的基础，并对系统集成与面向服务架构（SOA）实施细节的各个方面进行介绍，理论与实践并重。
□ 第1章 如何成为一名架构师：首先与读者一起建立我们讨论的共同起点，指出成为一名合格架构师的方向和路线草图，并初步勾勒出合格架构师必备的素质。同时，指导读者设立一种能够进行系统集成开发的技术环境。
□ 第2章 为什么要进行系统集成：对系统集成的历史、必要性、大原则及实施预后进行初步的讨论。
□ 第3章 系统之间相互作用的模式：主要探讨参与集成的各个系统之间相互作用的方式、适用范围及其优缺点。
□ 第4章 常见的参与集成的功能系统：列举常见的参与集成的系统本身的功能，比如数据库、客户管理系统（CRM）、企业资源计划（ERP）系统、BPM、复杂事件处理（CEP）等，以便读者对经常碰到的、需要进行集成的系统有一个大致的了解。
□ 第5章 究竟何为服务：这是一个老话题，但常常没有说清楚。
□ 第6章 系统集成项目的实施步骤：介绍典型的系统集成项目的具体实施细节，包括整个生命周期的各个环节。
□ 第7章 具体项目与公共服务：介绍如何将每个具体项目都需要使用的普遍性的服务模块单独进行开发，并利用标准化的项目模板来对每个具体项目进行实施，从而避免公共服务功能部分的重复实施，让每个项目专注于解决各自具体的业务问题。公共服务除了与业务有关的部分外，还包括安全、监视和管理以及运行维护方面的内容，但这部分内容不是本书的重点，仅仅是围绕重点涉及到的话题，所以点到为止。
□ 第8章 SOA的实施、局限性及解决方法：回顾SOA应用十几年来所产生的效果，分析其局限性，以及相应解决方法的展望。
• 第2部分在第1部分的基础上引入现代API的概念，并就API对于企业业务发展的意义、围绕API开发工作的具体细节、API与其他相关技术的关系等，结合实践进行详细的阐述。
□ 第9章 现代API的引入及应用互联网的概念：介绍API的概念、使用API后企业对业务和IT可期待的愿景，以及API与系统集成的关系。
□ 第10章 围绕API的开发工作的内容：详细介绍API开发和应用中的技术细节、以API为主导的架构设计，以及对企业IT部门与业务部门之间的互动带来的影响。
□ 第11章 API与微服务：从理论和实践的角度论述API与十分流行的微服务之间的联系与区别。
□ 第12章 API与云计算：对API的部署环境，特别是目前迅速兴起的云计算环境，以及API的部署模式进行介绍。
□ 第13章 最佳实践的经验：对开发和应用API的过程中积累下来的经验及教训进行总结和概括。
□ 第14章 API经济：当每一个企业以及企业里的每一个项目都按照API的架构思想进行实施，业务资源以API的形式系统地呈现时，就会形成一个应用网络（Application Network）。而这个网络也是企业价值链的网络，即以API支撑的经济体。这一章将对API经济进行初步的介绍，并引入企业数字化转型的话题。
• 第3部分是技术以外的随感。
□ 第15章 架构师的人文情怀：这部分内容天马行空，对技术方面的感悟、与人沟通的软实力、架构师的教育和职业规划，甚至学习过程的分析等都有涉及，十分随意。1.8 总结
本章首先澄清了什么是架构，什么是架构师。然后对不同阶段和不同角色的相关人员目前就大型复杂系统架构的理解所处的状态进行了分类，作为学习过程中不同阶段的代表。
随后，本章列出了一份通往架构师之路的路线图简介，同时还抛出了作者眼里优秀架构师必须具备的素质，以及针对成为架构师的学习过程的几点建议。本书各章的内容安排也是按照这个路线图展开的。
和其他很多技能一样，成功地成为一名优秀的架构师必须通过实践，没有“捷径”可走。本章最后选用（而不是推荐）了可以免费获得的一个系统集成及API的开发和部署平台，供读者练手，并得以对抽象的设计原则利用实例进行具体的说明。
在这个历程的终点回报丰厚，而过程本身也可以是充满乐趣的。你准备好了吗？—— 第1部分 ——基础篇
软件系统之所以越来越复杂，是因为其实施所要求的业务逻辑所牵涉的系统越来越多。当一个解决方案架构所包含的功能系统数目增多时，系统之间的互动自然也会增多；系统之间的协调和集成也自然会变成解决方案架构中重要的组成部分。
尽管系统集成、服务，以及面向服务架构都已经是老话题了，然而，很多人对这些话题中的基本概念还很模糊；做出来项目的结果依然还是犯点对点集成的错误架构。因此，在介绍本书的重点即现代API之前，我们针对这些话题作一个系统性的回顾，这样一来可以帮助新入行的开发人员从头学起、有经验的架构师复习回顾；二来也为学习第2部分的内容打好扎实的基础。作者相信，即使是经验丰富的系统集成架构师，也会从第1部分的内容中受益。 第2章 重新看待系统集成2.1 系统集成历史的快速回放
只要做过几年的企业级IT系统和应用的设计与开发，或者参与过客户公司的IT咨询项目，你就会发现，几乎没有一个项目是从“一张白纸”开始写起的。恰恰相反，每一个项目都需要保留和利用数个，甚至数百个现有的应用和系统（作者曾经碰到过需要集成超过50个现有系统的客户咨询项目）。这些应用和系统有的是商业软件应用，有的是公司自己开发的，还有的本身就是一个涉及多个应用的系统，将其中的数据资源分享给其他应用和系统，或以某种标准的形式（比如Webservices）呈现出来，或者利用这些现有的系统和应用来完成实施全新的业务流程。
每个现有的应用和系统可能都已运行多年，保存着大量宝贵的业务数据，并有很多的业务用户每天都在依赖这些系统和应用来完成他们的工作。如果这样还不够复杂，在这些系统和应用之上还常常二次开发出了更多的工具和应用。所以，将这些现有的应用和系统全部推倒重来是不可能的。
然而，这些系统和应用盘根错节，相互依赖，给整个系统的维护和升级以及新功能开发带来了不小的挑战。从软件工程的角度来说，对于如何应对这些复杂的系统和应用有什么好的办法呢？
全世界有成百万甚至上千万的程序开发人员，无论是科班出身还是半路出家，每个开发人员大致的成长之路都是从计算机硬件及软件的基础理论开始，包括学习算法和数据结构，然后挑选一至几种最广泛使用的计算机语言，比如通用的Java、C++、.NET、Python，以及工作中遇到的特殊用途语言等，就这些语言本身的语法和功能进行学习和训练，同时了解和熟悉一些数据库的设计和开发知识。这样，就可以开发出很多的计算机软件系统和应用了。
世界上的确有大量的应用比较简单，最多也就是3层的“网页-Web服务器－数据库”这类的“模型－视图－控制器”（Model-View-Controller）架构。事实上，多年以前Sun公司就发布过关于J2EE的架构模式（pattern）目录，来指导Java企业版的解决方案架构师们设计出优美的、灵活应变的应用架构。
现在，作为一个IT咨询公司的技术总监或是解决方案架构师，或者公司里的企业架构师，面对的是成百上千个现有的小系统和应用：包括Java、C++、.NET、PowerBuilder，甚至Mainframe，另外，还有大量的数据库里的存储过程（Stored Procedures），再加上大型的ERP系统、客户管理系统（CRM）、业务流程管理系统（BPM）等，还有采用上面的3层架构的网站，要怎么做才能把这些看似杂乱无章的系统和应用集成起来呢？
首先看看我们是怎么走到今天这一步的：
• 20世纪70年代，商务运行中占绝对优势的是Mainframe系统，其特点是运行过程和数据都高度集中在一台机器上，专注于实现业务功能的自动化。然而，这样的系统费用昂贵，使用独家特殊的技术，对用户也绝对不友好。
• 20世纪80年代，随着个人电脑和局域网的普及，各个业务部门的用户开始使用个人电脑进行文字和图表的处理，而不再过多地依赖于IT部门的大型机。从这时开始，原来集中在大型机上的业务流程与逻辑开始慢慢地被分散到个人电脑中，为今后系统集成的需求埋下了伏笔。
• 20世纪90年代，随着网络的普及和Internet的出现并成为行业标准，企业的信息和资源进一步地扩散到企业的各个部分，甚至跨出企业的范围之外，扩散到客户和合作伙伴那里，进一步带来了资源共享、集中监控和企业学习等方面的困难。这时的企业高管们已经开始意识到，需要对系统和数据进行集成和整合了。到了这个时期，已经很难再找到与外界没有任何联系的、孤立的系统和应用了。
• 21世纪初，企业变得更加大型化和全球化。企业和客户、合作伙伴、供应商、分销商以及企业内部员工之间的互动愈加频繁。在这个阶段，企业高管们关心的是数据共享以及如何基于及时、准确的数据做出相应的战略决策。
• 2010年后，企业高管们依然关心数据共享和基于数据的战略决策。然而这一次，企业资源和服务的标准化成为具体实施的主题，具体措施包括软件技术和方法论，以及企业里相应的组织机构方面的调整。结合方兴未艾的云平台、物联网和大数据技术，逐渐明确了IT部门的作用是为了促进和推动企业能够快速应变，推动企业的快速创新。这个趋势要求架构师的眼界更加开阔，对IT技术和企业业务的认识更加深刻，并更加积极地参与到企业的业务决策过程中去。2.2 到底什么是系统集成“系统集成”这个词每个人都知道，或者都听说过。我们还是落落俗套，问一问这个最初级的问题：什么是系统集成？（请你先不要往下看，先把你自己对这个问题的回答写在一张纸上。）
在过去的三年里作者曾对200多位服务咨询架构师职位的申请者进行技术面试。我最喜欢问的一个问题是：“你迄今为止最具挑战性的项目是哪一个？描述一下项目要求、挑战性何在以及你的解决方案的关键之处。”
75%的申请者会这么说：“是×××公司的×××项目。在那个项目里客户要求我们把SAP中的客户订单信息导入一个SQL Server的数据库，然后通过Tomcat的Web服务器由浏览器呈现给用户”。
项目出资人原本的问题是为客户提供及时的订单更新信息。他们很可能连什么是SAP、SQL Server都不知道，也不关心。我们在第15章会再回到这个话题上来，并更深入地阐述时时牢记“做什么”（WHAT）对项目的方方面面所产生的深刻的影响。
按照维基百科的说法：系统集成在工程中被定义为将各个相关的子系统整合到一个总系统之中的过程。各个子系统之间相互协作，以便总系统能够提供新的总体功能，并确保子系统作为总系统中的一部分正常运行。而在信息技术中，系统集成是在物理连接或功能上将不同的计算系统和软件应用程序组合成一个协调的整体。
还是有点儿抽象，是吧？我们来看看几个有代表性的例子吧。
• 信息更新：SAP系统中有些业务对象的某些属性的源头并不是在SAP中，而是可能在一个Oracle数据库中。每当这些属性在Oracle数据库中被更新后，新值会通过SAP IDOC的调用传入SAP。
• 信息组合：为了显示一个行业协会会员的个人基本信息以及会费缴付现状，需要将从Saleforce CRM系统中调取的会员信息和从企业自己开发的会员管理系统中取出的会员缴费信息组合在一起，并用一种普遍采用的标准化的方式呈现出来。
• 连锁行动：这种情形的系统集成有时会十分复杂。例如，一个网上新的客户订单被系统接收后可能会引发一系列的连锁事件（这些事件的顺序可能并不重要）。
□ 如果客户有信用额度，要检查信用额度是否超过上限并根据信用额度检查的结果决定是否接收订单。
□ 检查新订单是否会让该客户的VIP会员等级有所变化。
□ 检查库存。如已低于某个预设的下限，则触发新的生产或外协订购请求。2.2.1 系统集成之信息更新
大多数的系统集成项目的实施属于这一种，究其原因可能是因为“很直观，容易理解”。我们先来研究一个具体例子：如果A程序要跟B程序分享数据，都有哪些方法可以实现呢？直观地，即便没有做过任何稍具规模的系统集成项目，你也会想出以下几种方式。
• 如果A程序跟B程序运行在同一个内存空间里，A程序将数据处理的结果放在B程序可以访问的内存地址上（比如通过子程序的调用所返回的数据）。只可惜，实际应用中遇到的集成问题绝大多数不是这种情形，因为A程序和B程序运行在两个不同的环境里，无法共享内存。
• A程序将数据处理的结果存入某种格式（比如固定数据单元长度或特定字符分隔的csv）的文件。对于大量数据批处理的情形，这样的数据分享/集成方式依然很普遍。然而，处理这样的文件的具体逻辑需要数据源和数据目标系统另外单独在系统外进行沟通，这就严重影响了数据的通用性；另外，以文件的形式传送数据（本地或映射的文件夹、各种FTP服务器等）在强调实时的应用中有着许多明显的缺陷，最显著的缺点是数据无法“随到随走”，而且处理的速度要慢些，因为I/O的速度比存储器的调用速度要慢得多。
• A程序将数据处理的结果存入某个数据库，再由B程序从数据库中将该处理结果取出。这种方式与文件方式相比更容易安排，且数据库的事务管理（Transaction）使得数据的传送更为可靠。然而，文件方式中存在的缺点，如数据无法“随到随走”，以及I/O速度的问题在此依然存在，而且也要考虑数据库本身的软件版权和支持费用。
在最近的15年里，计算机内存价格下降的速度远远大于硬盘价格下降的速度。而基于内存、不涉及I/O的系统之间的数据交换逐渐成为主流。这包括同步调用和异步调用，即调用者等待或完全不等待调用结果的返回这两种情形。基于SOAP/XML的Webservices调用和JMS的消息发布即是这两种调用方式具体的例子。
在具体实施上，绝大多数人立即想到的、最自然的办法是：
定义哪些数据需要从源系统导入目标系统（比如顾客的姓名、电话和电邮）；找到从源系统中取出这些数据的方法（比如Salesforce SOAP API调用、SAP BAPI调用、数据库JDBC调用，等等），并取得数据；最后看怎么将数据存入目标系统中（同样地，比如Salesforce SOAP API调用、SAP BAPI调用、数据库JDBC调用，等等）。大功告成！
且慢！这种“最自然的”方法存在着诸多问题（顺便提一句，凡是涉及某种技能的培养，最正确、有效的做法往往和“最自然的、最本能的”方式恰恰相反，比如滑冰时正确的方式是将重心放在前脚上，恰恰与人走路时最自然的重心放在后脚上的本能相反。这样的例子比比皆是）。
1．从头到尾都是封闭的、点对点式的调用。如果同一个源系统的信息还需要导入其他两个目标系统，从源系统中导出数据的工作就需要重复3次，并做3次不同的数据转换。如果分在不同的项目中完成，同样工作的实施可能重复进行，并且相互之间不一致。当总的系统数目超过5个时，整个系统集成的复杂程度就会失去控制，如图2-1所示。
2．每次导出的信息只是只言片语。只看“姓名、电话和电邮”这几个指标，你知道在谈什么吗？导出的数据完全无法重复利用。
3．设计和实施的人员必须十分了解有关对源系统和所有的目标系统进行调用的技术细节。而通常熟悉多个企业版软件系统还有企业自己开发的非标系统的技术人员很难找到。图2-1 “点对点”进行信息更新式的系统集成所造成的复杂程度
4．对目标系统中那些需要从源系统中不断进行更新的数据项，永远没有100%的信心明确地知道，这些数据目前的值是准确的，而不是源系统中已被更新、马上又要有更新值进来；或者负责从源系统到目标系统的不断更新的通道出了问题。如果从目标系统中调用了过时的数据在业务上并没有什么严重的后果，或者数据的更新并不频繁，那么，可能造成的问题并不会太严重。但如果使用过时的数据可能造成业务上的重大损失，那就不能再采用这样的方式了。
5．每个企业级系统的安全措施都不一样，这样的集成方案中要做到妥善保存和管理多个企业关键系统的保密信息非常困难。而诸如调用速率限制（Throttling）等针对调用者的具体政策（policy）更是无法实施。
6．在有些源系统到目标系统的更新十分频繁的情形里，在目标系统中的数据两次被调用之间可能发生了多次的从源系统到目标系统的数据更新。从CPU、内存、网络带宽到日志文件的记录等系统资源方面来说，这些中间的更新完全是浪费。更糟糕的是，如果在这些无用的更新过程中发生了错误，还要浪费技术支持团队的时间来搞明白发生了什么，并处理那几个毫无影响的错误。2.2.2 系统集成之信息组合
如果要保证调用数据所得到的结果永远是准确的、最新的，唯一的办法是每一条数据都是从其真正的源头系统（True System of Record），而不是从第二手甚至第三手的系统中提取出来的，然后对得到的数据进行组合。这样的做法避免了数据更新，不用担心拿到过时的数据。然而，这样的做法也可能存在相当多的问题。
1．如果信息组合所涉及的源系统有多个，包括的数据过多，对所有的数据源系统进行调用并将信息进行组合，花费的总体时间可能会过长。
2．为了尽可能地重复利用这些从多个源系统取出并经过组合的数据，往往需要花很多时间来设计最终呈现的业务数据的格式。由于涉及人员之广、调用数据的系统和应用对数据要求之多样化，这些数据资源的格式设计非常具有挑战性。我们会在2.3.3节中具体讲述这个话题。例如，每个不同调用数据的系统可能只需要（通用）数据调用结果的一小部分，而每个系统所需要的部分又各不相同。
3．如果对某个数据源系统的调用出现了问题，如何处理每一种出错的情况可能会比较困难。比如，一个为最终通用的数据调用结果贡献5%数据项的源系统出了问题，那么根本不需要这5%数据的调用系统是否也应该受到惩罚、根本拿不到自己所需要的数据呢？对这个问题的思考和回答显然大大增加了设计的复杂性。2.2.3 系统集成之连锁行动
这种情况是上述系统集成的3种情形中最复杂的一种。为了能够深入理解这种系统集成情形所真正面临的挑战，我们还是先来讲个故事吧。
很久很久以前，在一个很遥远的地方只有几个小村庄。每个村庄里的人们都自己种地、捕猎、纺织，自给自足，从不与外面的世界打交道，也不需要别人的帮助。这是一幅宁静安详的田园画面，村庄之间鸡犬相闻，但村与村之间老死不相往来。
直到有一天，有的村民要把自己吃不完的粮食、穿不完的布匹去换回他们短缺的日用品。他们计划到其他村子去看看。由于多少代人以来，大家从来不相互走动，村与村之间是没有道路的。于是，这些村民“自然而然地”在他们自己的村子与每一个他们想去走走的村子之间修一条路，然后沿着每一条这样的路去每一个村子试试运气。
过了一段时间，村子之间的交通初具规模，成了图2-2所示的样子。
虽然还有些不便，比如村子3的人要到村子6去就有点儿麻烦，但总的来说路线的设计“自然而然”，修起来也快，所以大家也就接受了这种做法。图2-2 第1轮在村与村之间修建的道路
这些人的运气不错，引来更多的人效仿，而且他们走动的范围越来越大，去的村子也越来越多。随着时间的推移，问题来了：
• 开辟出来连接村与村之间的道路越来越多，不仅占地过多，维护费用高昂，还像迷宫一样把人给搞糊涂了。
• 如果一次想串几个村子，很难找到一条最有效的路径（村民们可没上过算法课）。
• 有些道路只有少数几个村子的村民会用到，而另外一些村子的村民则很少或永远也不会用到。这就引起了村庄之间在道路的修建和维护费用分摊上难以避免的摩擦和纠纷。
现在村子之间的道路格局变成了图2-3所示的样子（等等！怎么跟图2-1一模一样啊！）。从使用、维护和扩建的任何方面看都无法长期维持下去。
最后各村共同决定，重新设计道路交通。这次，考虑到优化道路的数量和长度、让公共道路部分最大化、简化新的村子加入交通系统的过程，以及对将来与外地的交通系统相连接的考虑，大家设计出如图2-4所示的道路系统。
图2-4所显示的道路系统具有以下几个特点。
• 所有村子不再直接与任何其他村子相连接，而是就近连接到2一条或多条高速公路上。这样，道路的总数就从N的量级降到了N的量级。
• 高速公路的设计、修建和维护费用由所有的村子按人口分摊。图2-3 村子之间的道路越修越多、越修越乱图2-4 经过初次修改的村子之间的道路交通系统
• 各村连接到高速公路的道路及高速入口、出口的设计、修建和维护费用由各村自己解决。
• 新的村子加入这个交通系统按上述两条进行安排和实施。
故事到这儿并没有结束。随着使用这个交通系统的村民越来越多，高速公路又带来了外地的商人，高速公路上和进入各个村子的小路上事故不断。加上每个村子与高速相连的道路是由各村自行修建，其规格性能各异。比如有些村子只有小型驴车和人力平板车，修成的窄窄的与高速相连的路上其他村子的四匹高头大马拉的马车根本无法行走。同时，由于货物交易量大大增加，催生了专门为村民跑路进行货物运输的生意。而这些负责运输的人对货物千姿百态的运输形态和包装头痛不已。
针对这些出现的新问题，各村再次进行协调和商议，对这个交通道路系统进行了第2次修改。
• 各村与高速公路相连接的道路必须满足一定的基本要求。
• 在高速上和本地道路上安装交通灯、指示牌等调度指挥装置。
• 增加道路行车记录和事故处理的公共服务。
• 制订固定的、标准尺寸的货运专柜，大大方便运输过程中对货物的处理。
上面这个故事作者在进行IT咨询项目的过程中至少给20个客户讲过，十分有效，尤其是对于从来没有过系统集成经验的人。当设计和实施的过程中遇到困难，或者需要对不同的设计方案进行优缺点的比较时，这个故事也经常可以很好地帮助作者进行方案优缺点对比的详细论述。
我们还可以用另外一个比方来进行系统集成基本概念和设计原则的阐述。
大家都不喜欢开会，尤其是程序员们，总觉得开会是在浪费时间。其实开会只是一种手段，而背后需要解决的问题是沟通，尤其是牵扯的人比较多、每个人的利益不同而你又需要所有人不同形式的支持和通力合作时，开会大概是最有效的沟通方式了。如果个别交流，每一对成员之间都需要单独沟通，总体沟通的效率就会十分低下。而如果采用开会的方式，由某个有威望的人主持会议，并将会议讨论内容限定在预定的话题范围内，那么整个群体的沟通就会变得十分有效，问题也能得到很好、很快的解决（见图2-5）。
会议主持者的作用就是协调与会者进行有效的交流和沟通，并就会议议程中的每一项议题达成认知和行动上的共识。由此，点对点、2一对一的N量级的沟通复杂性变成了一对多、N量级。同时，每一位与会者都将与本次会议无关的、个人及所代表的团队的特点、想法和行动通通暂时掩藏起来，集中全部精力思考和解决目前手头上的问题。图2-5 系统集成的设计与开会的相似之处
系统集成的设计思想有很多都可以从上面两个比方中得到借鉴。
为了彻底解决这种类型的问题，系统集成引进了BUS的概念。在此，每个参与集成的系统都不再与其他任何系统直接点对点地进行连接，而是各自连接到BUS上。这个BUS就有点像山村故事里的高速公路，或者是开会时的会议桌。
每个系统在连接到BUS上时，需要通过一个特定的机制（见图2-6中的灰色部分），叫做连接器（Connector）或者适配器（Adapter），其功能就是将每个涉及的系统与当前的用例（Use Case）有关的功能、数据呈现在BUS上。每个系统与BUS之间的互动有4种形式（见图2-6）。图2-6 系统集成中涉及的各个系统通过连接器/适配器与BUS相连
试读结束[说明：试读内容隐藏了图片]