阿里妹导读：从十余年前的各种分布式系统研发到现在的容器云，从支撑原有业务到孵化各个新业务，企业的发展离不开统一的、与时俱进的技术架构。本篇文章从企业分布式应用架构层面介绍了云原生计算架构带来的变化，希望能够帮助更多企业的IT转型，利用云计算技术推动其成为市场竞争中的敏捷力量。
进入21世纪以来，我们见证了企业分布式应用架构从SOA(Service-orientedArchitecture)，到微服务架构，再到云原生应用架构的演化。为了说明企业架构演化背后的思考，我们先谈一些玄学。第一，企业IT系统的复杂性（熵）符合热力学第二定律。随着时间的推演，业务的变化，企业IT系统的复杂度会越来越高；第二，在计算机交互设计中有一个著名的复杂性守恒定律[1]。应用交互的复杂性不会消失，只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构，不会降低IT系统的整体复杂性。听到这里，是否让生命不息、折腾不止的我们感到一丝凉凉？现代软件架构的核心任务之一就是定义基础设施与应用的边界，合理切分复杂性，减少应用开发者需要面对的复杂性。换句话说，就是让开发者专注在核心价值创新上，而把一些问题交给更合适的人和系统来解决。我们就从下面这张图开始，探究企业分布式应用架构演进背后的逻辑。本图来自BilginIbryam的twitter[2]蜕变之痛：SOA年，IBM建立SOA全球设计中心，我作为研发TL和架构师参与了一系列全球客户的pilot项目，帮助Pepboys,OfficeDepot等国际企业利用SOA优化企业内部和企业间的业务流程，提升业务敏捷性。当时的大背景是：随着经济全球化逐渐深入，企业面对的竞争加剧，商业变革也开始提速。在大型企业内部的IT系统已经经过了数十年的演化，整个的技术体系变得异常复杂，并存着诸如主机系统上的CISC/COBOL交易应用，小型机AS中的RPG业务系统，和X86/Power等分布式系统的C/JEE/.Net应用。大量应用系统由三方供应商提供，一些系统甚至已经无人维护。而且随着业务迭代，一些新的业务系统被持续构建出来，由于缺乏合理的方法论指导，系统之间缺乏有机的链接，形成了若干的孤岛，持续加剧了IT架构的复杂性，无法支撑业务的发展诉求。这就仿佛各派高手为了帮助受伤的令狐冲，把异种真气输入体中，虽然短时间可以缓解伤势。可是多道真气无法融合，互相激荡，长时间下来会伤上加伤。因此，企业IT所面临的首要挑战就是整合企业中大量竖桶型（silo-ed）的IT系统，支撑日益复杂的业务流程，进行高效的业务决策和支撑业务快速变化。在这种背景下，IBM等公司提出了SOA（面向服务的架构）理念，将应用系统抽象成一个个粗粒度的服务，构建松耦合服务架构，可以通过业务流程对服务进行灵活组合，提升企业IT资产复用，提高了系统的适应性、灵活性和扩展性，解决“信息孤岛”问题。SOA提出了一系列构建分布式系统的原则，这些思考直到今天也依然适用：服务具备明确定义的标准化的接口。通过服务定义描述，将服务消费者（ServiceConsumer）和服务提供者(ServiceProvider)的实现进行解耦，并且服务应该采用contract-first而非code-first方式进行开发。服务间通信采用面向文档的消息而非特定语言RPC协议，一方面可以解决服务与实现语言的解耦，另一方面可以灵活选择同步或者异步的通信实现，提升系统可用性和可伸缩性；服务应该是松耦合的，服务之间不应存在时间、空间、技术、团队上的依赖；服务应该是无状态的，使得服务调用与会话上下文状态实现解耦；服务应该是自治和自包含的，服务的实现是可以独立进行部署、版本控制、自我管理和恢复；服务是可发现、可组合的。比如可以通过ServiceRegistry进行服务发现，实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。在初始构建SOA系统的时候，大多采用点对点的通信连接，服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候，确实是一种简单和高效的开发方式。但其最大的问题是，随着服务规模的增长，服务之间通信愈发复杂，连接路径和复杂性会剧增，给服务治理带来巨大的挑战。为了解决上述挑战，企业服务总线(EnterpriseServiceBus，ESB)开始被引入。企业服务总线提供了服务之间的连接（connection），转换（transformantion）,以及中介处理（mediation）的能力。可以将企业内部和各种服务连接到服务总线上，实现信息系统之间的松耦合架构，屏蔽了系统集成的复杂性，提高了IT系统架构的灵活性，降低企业内部信息共享的成本。SOA方法论的目标就像易筋经可以帮助梳理、归聚不同的真气，融会贯通，为我所用。然而修炼过程却绝非易事。大量雄心勃勃的SOA项目并未取得预期的效果，其背后的原因是什么？任何IT架构的成功，都离不开与业务目标、技术基础和组织能力的相互配合。在业务上，当时SOA重点解决的是企业IT的存量市场的问题。这使得SOA方法论很大程度被窄化为EnterpriseApplicationIntegration（EAI企业应用集成)。在SOA理念中，打通信息系统间的经络只是第一步，还需要勤修内功，持续重构迭代企业IT架构，这样才能保持企业IT架构的敏捷、柔性，持续支撑业务的发展和变化。在组织结构上，由于当时在大部分企业的IT部门仍然是成本中心，是业务的附属支撑部门，大多数企业缺乏长远的IT战略规划，IT团队也缺乏成长认同，SOA沦为项目制运作而没有组织化保障和持续投入。即使当时成功的项目也会在复杂性日积月累的侵蚀下，逐渐失去活力。去年在美国生活的朋友发过来照片，15年前我们为客户构建的业务系统还在支撑其现有全国门店的业务。这是技术项目的成功，却反映了企业技术战略的缺失。在技术上，ESB架构虽然实现了业务逻辑与服务集成的解耦，可以更好地进行中央化的服务治理，也暴露出一些严肃问题：由于过度强调业务系统的可复用性，而不是对企业IT架构的治理和重构。大量服务集成的实现逻辑被下沉到ESB内部（如上图最右侧所示），这些逻辑非常难以维护，难以移植和扩展，成为ESB不可承受之重。我们必须在合适的地点合理地处理复杂性，而非将其简单转移；ESB基于一个中心化的消息处理系统，但随着互联网的高速发展，ESB已经无法应对企业IT规模化成长的挑战；ESB这样的SmartPipes,Dumbendpoints的系统架构是一个无法适应快速变化和大众创新的一个架构。
类比一下，电信运营商曾经希望将视频通信，电话会议等复杂功能纳入电信基础设施，只需一个Dummy电话终端就可以享受丰富的通信服务。然而随着智能电话的普及，转载请注明：http://www.0431gb208.com/sjszjzl/1311.html
