进入21世纪以来，我们见证了企业分布式应用架构从SOA（面向服务的架构）到微服务架构，再到云原生应用架构的演变。
为了解释企业架构演进背后的思考，我们先来说一些“玄学”：
l企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推移和业务的变化，企业IT系统的复杂度会越来越高。
l计算机交互设计中有一条众所周知的复杂性守恒定律：应用程序交互的复杂性不会消失，只会以另一种方式存在。这个原则也适用于软件架构，即引入新的软件架构并不会降低IT系统的整体复杂性。
听到这里，是不是让不断为生活而奋斗的我们感到一丝清凉呢？
现代软件架构的核心任务之一是定义基础设施和应用程序之间的边界，合理分割复杂性，降低应用程序开发人员需要面对的复杂性。换句话说，它让开发者能够专注于核心价值创新，而把一些问题留给更合适的人和系统去解决。
我们从图I-1开始，探索企业分布式应用架构的演进。
转型之痛——SOA
年，IBM成立了SOA全球设计中心。作为研发TL和架构师，我参与了一系列面向全球客户的试点项目，帮助PepBoys、OfficeDepot等国际公司利用SOA优化企业内部和企业间的业务流程，提高业务敏捷性。性别。
当时的大背景是，随着经济全球化逐渐深入，企业面临的竞争加剧，商业变革开始加速。大型企业内的IT系统已经发展了数十年。整个技术体系变得极其复杂，主机系统上有CISC、Cobol交易应用，小型机AS/上有RPG业务系统，还有X86或Power等分布式系统上的C、J2EE、.Net应用并存。大量的应用系统是由第三方供应商提供的，有的系统甚至无人维护。而且，随着业务迭代，一些新的业务系统不断构建。由于缺乏合理的方法论指导，系统之间缺乏有机联系，形成了多个“信息孤岛”，不断增加IT架构的复杂性，无法支撑业务发展需求。就好像各门高手将异气注入体内，来帮助受伤的令狐冲一样。虽然伤势可以在短时间内缓解，但诸气无法融合，互相激荡，长此以往会造成更多的伤害。
因此，企业IT面临的首要挑战是整合企业内大量孤立的IT系统，以支持日益复杂的业务流程，做出高效的业务决策，并支持快速的业务变革。在此背景下，IBM等公司提出了SOA（面向服务的架构）的概念，将应用系统抽象为粗粒度的服务，构建松耦合的服务架构。可以通过业务流程灵活组合服务，提高企业IT资产的复用性，提高系统的适应性、灵活性和可扩展性，解决“信息孤岛”问题。
SOA提出了一系列构建分布式系统的原则，这些原则至今仍然适用：
1）服务有明确定义的标准化接口，通过服务定义描述解耦服务消费者（consumer）和服务提供者（provider）的实现。服务应该以契约优先而不是代码优先的方式开发。服务之间的通信使用面向文档的消息而不是特定于语言的RPC协议。一方面可以解决服务与实现语言的解耦。另一方面，可以灵活选择同步或异步通信实现方式，提高系统可用性和可扩展性。
2）服务应该是松耦合的，服务之间不应该存在时间、空间、技术、团队上的依赖。
3)服务应该是无状态的，以将服务调用与会话上下文状态分离。
4）服务应该是可重用的，业务逻辑被划分为一系列可重用的服务。
5）服务应该是自治和自包含的，服务实现可以独立部署、版本控制、自我管理和恢复。
6）服务是可发现和可组合的。例如，可以通过服务注册中心来执行服务发现，从而实现服务消费者和服务提供者的动态绑定。在业务流程中，来自不同系统的业务服务可以被编排和组装。
最初构建SOA系统时，大多数系统使用点对点通信连接，服务调用和集成逻辑嵌入在应用程序实现中。这种方法在服务数量比较少的情况下确实是一种简单高效的开发方法。但其最大的问题是，随着服务规模的增长，服务之间的通信变得越来越复杂，连接路径和复杂度都会急剧增加，给服务治理带来巨大挑战。
为了解决上述挑战，企业服务总线（ESB）开始被引入，如图I-2所示。企业服务总线提供了在服务之间连接、转换和中介服务的能力。它可以将企业和各种服务连接到服务总线上，实现信息系统之间的松耦合架构，屏蔽系统集成的复杂性，提高IT系统架构的灵活性，降低企业内部信息共享的成本。
SOA方法论的目标就像《易筋经》一样，能够帮助人们理清、汇聚诸气，融汇为我所用。然而，培育的过程却绝非易事。大量雄心勃勃的SOA项目并没有取得预期的成果。这背后的原因是什么？
阿里云开传奇教程_阿里云服务器开传奇_阿里云传奇版本架设教程任何IT架构的成功都离不开与业务目标、技术基础和组织能力的配合。
从业务上来说，SOA当时的重点是解决企业IT现有的市场问题。这在很大程度上将SOA方法论缩小为企业应用集成（EnterpriseApplicationIntegration）。在SOA理念中，打通信息系统之间的经脉只是第一步。还要苦练内功，不断重构迭代企业IT架构，保持企业IT架构的敏捷性和灵活性，持续支撑业务发展和变革。
从组织架构上来说，由于当时大多数企业的IT部门还是成本中心，所以是业务支撑部门。大多数企业缺乏长期的IT战略规划，IT团队缺乏对成长的认识。SOA被简化为基于项目的操作，没有组织保障和持续投资。即使当时成功的项目也会随着时间的推移在复杂性的侵蚀下逐渐失去活力。去年，一位住在美国的朋友给我发了一张照片。我们15年前为客户建立的业务系统仍然支撑着其现有的全国门店的业务。这是技术项目的成功，却反映出企业技术战略的缺失。
从技术上来说，ESB架构虽然实现了业务逻辑和服务集成的解耦，但能够更好地实现中心化的服务治理。一些严重问题也被暴露出来：
1）由于过于强调业务系统的复用性而不是企业IT架构的治理和重构。大量的服务集成实现逻辑被推入ESB，导致ESB滥用。如图I-2最右图所示，这些逻辑非常难以维护、移植和扩展，已经成为ESB难以承受的负担。我们要把复杂性处理在正确的地方，而不是简单地转移。
2）ESB基于集中式消息处理系统。随着互联网的快速发展，ESB已经无法应对企业IT大规模增长的挑战。
3）像ESB这样的“智能管道、哑端点”的系统架构是一种无法适应快速变化和大规模创新的架构。以此类推，电信运营商曾经希望将视频通信、电话会议等复杂功能融入到电信基础设施中，只需要一个“哑巴”电话终端就可以享受丰富的通信服务。然而，随着智能手机的普及，
转载请注明：http://www.0431gb208.com/sjszjzl/9223.html
