品牌网站建设黑白I狼J,东莞网站推广需要多少钱,wordpress直接访问站点,wordpress更改站点ip进入21世纪以来#xff0c;我们见证了企业分布式应用架构从SOA(Service-oriented Architecture)#xff0c;到微服务架构#xff0c;再到云原生应用架构的演化。
为了说明企业架构演化背后的思考#xff0c;我们先谈一些玄学。
第一#xff0c;企业IT系统的复杂性#…
进入21世纪以来我们见证了企业分布式应用架构从SOA(Service-oriented Architecture)到微服务架构再到云原生应用架构的演化。
为了说明企业架构演化背后的思考我们先谈一些玄学。
第一企业IT系统的复杂性熵符合热力学第二定律。随着时间的推演业务的变化企业IT系统的复杂度会越来越高。
第二在计算机交互设计中有一个著名的复杂性守恒定律。应用交互的复杂性不会消失只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构不会降低IT系统的整体复杂性。
听到这里是否让生命不息、折腾不止的我们感到一丝凉凉:-)
现代软件架构的核心任务之一就是定义基础设施与应用的边界合理切分复杂性减少应用开发者需要面对的复杂性。换句话说就是让开发者专注在核心价值创新上而把一些问题交给更合适的人和系统来解决。
我们就从下面这张图开始探究企业分布式应用架构演进背后的逻辑。 蜕变之痛 - SOA
2004年IBM建立SOA全球设计中心我作为研发TL和架构师参与了一系列全球客户的pilot项目帮助Pepboys, Office Depot等国际企业利用SOA优化企业内部和企业间的业务流程提升业务敏捷性。
当时的大背景是随着经济全球化逐渐深入企业面对的竞争加剧商业变革也开始提速。在大型企业内部的IT系统已经经过了数十年的演化。整个的技术体系变得异常复杂并存着诸如主机系统上的CISC/COBOL交易应用小型机AS400中的RPG业务系统和X86/Power等分布式系统的C/JEE/.Net应用。大量应用系统由3方供应商提供一些系统甚至已经无人维护。而且随着业务迭代一些新的业务系统被持续构建出来由于缺乏合理的方法论指导系统之间缺乏有机的链接形成了若干的孤岛持续加剧了IT架构的复杂性无法支撑业务的发展的诉求。这就仿佛各派高手为了帮助受伤的令狐冲把异种真气输入体中虽然短时间可以缓解伤势。可是多道真气无法融合互相激荡长时间下来会伤上加伤。
因此企业IT所面临的首要挑战就是整合企业中大量竖桶型silo-ed的IT系统支撑日益复杂的业务流程进行高效的业务决策和支撑业务快速变化。在这种背景下IBM等公司提出了SOA面向服务的架构理念将应用系统抽象成一个个粗粒度的服务构建松耦合服务架构可以通过业务流程对服务进行灵活组合提升企业IT资产复用提高了系统的适应性、灵活性和扩展性解决“信息孤岛”问题。
SOA提出了一系列构建分布式系统的原则这些思考直到今天也依然适用
首先是服务具备明确定义的标准化的接口通过服务定义描述将服务消费者Service Consumer和服务提供者(Service Provider)的实现进行解耦。并且服务应该采用contract-first而非code-first方式进行开发。服务间通信采用面向文档的消息而非特定语言RPC协议一方面可以解决服务与实现语言的解耦此外可以灵活选择同步或者异步的通信实现提升系统可用性和可伸缩性。服务应该是松耦合的服务之间不应存在时间、空间、技术、团队上的依赖。服务应该是无状态的使得服务调用与会话上下文状态实现解耦。服务应该是自治和自包含的服务的实现是可以独立进行部署、版本控制、自我管理和恢复。服务是可发现、可组合的。比如可以通过Service Registry进行服务发现实现了服务消费者和服务提供者的动态绑定。业务流程中可以对来自不同系统的的业务服务进行编排组装。
在初始构建SOA系统的时候大多采用点对点的通信连接服务调用和集成逻辑被内嵌在应用实现中。这种方式在服务数量比较少的时候确实是一种简单和高效的开发方式。但其最大的问题是随着服务规模的增长服务之间通信愈发复杂连接路径和复杂性会剧增给服务治理带来巨大的挑战。
为了解决上述挑战企业服务总线(Enterprise Service BusESB)开始被引入。企业服务总线提供了服务之间的连接connection转换transformantion, 以及中介处理mediation的能力。可以将企业内部和各种服务连接到服务总线上实现信息系统之间的松耦合架构屏蔽了系统集成的复杂性提高了IT系统架构的灵活性降低企业内部信息共享的成本。 SOA方法论的目标就像易筋经可以帮助梳理、归聚不同的真气融会贯通为我所用。然而修炼过程却绝非易事。大量雄心勃勃的SOA项目并未取得预期的效果其背后的原因是什么
任何IT架构的成功都离不开与业务目标、技术基础和组织能力的相互配合。
在业务上当时SOA重点解决的是企业IT的存量市场的问题。这使得SOA方法论很大程度被窄化为 Enterprise Application Integration EAI 企业应用集成)。在SOA理念中打通信息系统间的经络只是第一步。还需要勤修内功持续重构迭代企业IT架构这样才能保持企业IT架构的敏捷、柔性持续支撑业务的发展和变化。
在组织结构上由于当时在大部分企业的IT部门仍然是成本中心是业务的附属支撑部门。大多数企业缺乏长远的IT战略规划IT团队也缺乏成长认同SOA沦为项目制运作而没有组织化保障和持续投入。即使当时成功的项目也会在复杂性日积月累的侵蚀下逐渐失去活力。去年在美国生活的朋友发过来照片15年前我们为客户构建的业务系统还在支撑其现有全国门店的业务。这是技术项目的成功却反应了企业技术战略的缺失。
在技术上ESB架构虽然实现了业务逻辑与服务集成的解耦可以更好地进行中央化的服务治理。也暴露出一些严肃问题
由于过度强调业务系统的可复用性而不是对企业IT架构的治理和重构。大量服务集成的实现逻辑被下沉到ESB内部如上图最右侧所示这些逻辑非常难以维护难以移植和扩展成为ESB不可承受之重。我们必须在合适的地点合理地处理复杂性而非将其简单转移。ESB基于一个中心化的消息处理系统但随着互联网的高速发展ESB已经无法应对企业IT规模化成长的挑战。ESB这样的Smart Pipes, Dumb endpoints的系统架构是一个无法适应快速变化和大众创新的一个架构。类比一下电信运营商曾经希望将视频通信电话会议等复杂功能纳入电信基础设施只需一个Dummy电话终端就可以享受丰富的通信服务。然而随着智能电话的普及微信和钉钉这样的分布式协同工具创新彻底颠覆了人们沟通交流的方式而电信网络重回管道的宿命。
羽化之美 - 微服务
随着互联网的发展尤其是移动互联时代的到来整个世界的经济形态发生了巨大的变化改变。企业IT的重点从传统的System of Record交易系统如ERP, SCM等演化到System of Engagement互动系统如全渠道营销。这些系统需要能够应对互联网规模的快速增长并且能够快速迭代低成本试错。企业IT已经成为创新驱动的引擎之一技术拓展商业边界的理想也帮助IT团队更有使命感进一步加速推动了企业IT的进化。
以Netflix阿里为首的一系列互联网公司主导了企业架构新的变革 - 微服务架构。Apache Dubbo, Spring Cloud等微服务框架得到了广泛应用。
微服务的核心思想便是应用功能拆分与解耦降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务每个服务遵守单一责任原则Single Responsibility Principle。微服务架构解决了传统单体式架构存在的几个固有问题每个服务可以独立部署和交付大大提升了业务敏捷性每个服务可以独立横向扩展/收缩应对互联网规模的挑战。 当然将大型的单体应用拆解为多个微服务也一定会增加IT系统研发协同、交付、运维的复杂性。这时候微服务架构与DevOps和容器自然走到了一起构成了云原生应用架构的雏形。
微服务架构继承了SOA的架构原则但是在实现层面它倾向于通过构造智能端点和哑管道的去中心化分布式架构风格来替代ESB。邱小侠 在微服务Microservice那点事文中详细分析了这些问题我也不再赘述。
微服务架构首先要面对分布式架构的内生复杂性请参考 分布式计算的误区。微服务框架需要能够解决服务通信和服务治理的复杂性比如服务发现、熔断、限流、全链路追踪等挑战。微服务框架如HSF/Dubbo或Spring Cloud以代码库的方式来封装这些能力。这些代码库被构建在应用程序本身中随着应用一起发布和维护。 服务通信和治理本质是横向的系统级关注是与业务逻辑正交的。但在微服务架构中其实现方式和生命周期与业务逻辑耦合在一起的。微服务框架的升级会导致整个服务应用的重新构建和部署。此外由于代码库通常与特定语言所绑定难以支持企业应用的多语言polyglot实现。
进化之光 - 云原生
SOA采用中心化的服务总线架构解耦了业务逻辑和服务治理逻辑微服务架构回归了去中心化的点对点调用方式在提升敏捷性和可伸缩性的同时也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。
为了解决上述挑战社区提出了Service Mesh服务网格架构。它重新将服务治理能力下沉到基础设施在服务的消费者和提供者两侧以独立进程的方式部署。这样既达到了去中心化的目的保障了系统的可伸缩性也实现了服务治理和业务逻辑的解耦二者可以独立演进不相互干扰提升了整体架构演进的灵活性同时服务网格架构减少了对业务逻辑的侵入性降低了多语言支持的复杂性。 Google, IBMLyft主导发起的Istio项目就是服务网格架构的一个典型的实现也成为了新的现象级“网红”项目。 上图是Istio的架构逻辑上分为数据平面和控制平面。数据平面由一组以 sidecar 方式部署的智能代理组成负责截获应用网络流量收集遥测数据并且执行服务治理策略。控制平面中Galley负责配置管理Pilot负责下发配置Mixer负责策略检查和遥测数据聚合Citadel负责通信中安全证书管理。
Istio提供了一系列高阶的服务治理能力比如服务发现和负载均衡渐进式交付(灰度发布)混沌注入与分析全链路追踪零信任网络安全等。可以供上层业务系统将其编排到自己的IT架构和发布系统之中。
但是Service Mesh不是银弹其架构选择是通过增加部署复杂性sidecar和损失性能增加两跳来换取架构的灵活性和系统的可演化性。
为了解决部署复杂性的挑战社区和云服务商都在共同进行努力一方面提升服务网格自动化运维水平比如阿里云通过operator大大简化了Istio的升级运维和跨K8s集群部署的复杂度一方面提供托管的服务网格服务帮助用户关注在业务层面的服务治理而非基础架构实现。
关于性能问题一方面Service Mesh需要降低自身控制平面和服务平面的性能开销比如尽可能offload mixer负载将治理策略执行下沉到数据平面完成。还要需要重新思考整个通信栈中应用与网络基础设施的边界。为了实现容器应用之间的互联互通Kubernetes社区提出CNI网络模型将容器网络连通性与底层网络实现的进行解耦。同时K8s提供了Service, Ingress, Network policy等基本元语来支持应用层的服务通信和访问控制但是这些能力远不能满足应用对服务治理的需求。服务网格在L4/L7增加了流量管理、全链路可观测性、安全互联等新功能这些是通过引入运行在用户空间的Envoy代理实现的。在提升灵活性的同时也不可避免地增加了性能开销。为了系统化解决这个问题社区在进行有趣的探索。比如在Cillium容器网络中可以利用eBPF/XDP等操作系统和底层网络能力将应用层的服务控制能力如Kube-Proxy提供的service, network policy下沉到操作系统内核和网络层解决并优化了Service Mesh数据链路减少上下文切换和数据拷贝有效地减少了性能开销。 目前Service Mesh技术还处技术成熟度曲线的初期除了在L4/L7层提供灵活的服务通信功能社区也在探索通过网络Service Mesh实现灵活的L2/L3组网能力。我们相信其会成为未来企业分布式应用通信基础设施。 在这个过程中会有一些新的理念和项目被持续创造出来我们需要能够理性地分析其业务价值和技术局限性。我们要避免将Service Mesh作为万灵药不要将应用集成、应用侧安全等业务逻辑下沉到服务网格中避免我们重蹈复杂性覆辙。
回望历史
天下大势分久必合合久必分。企业分布式应用架构也走过一条分分合合的进化道路。在新技术迭起的今天我们既要拥抱新技术带来的架构变化更要加关注其背后的演进逻辑和核心价值系统化地控制复杂性。
本文从企业分布式应用架构层面介绍了云原生计算架构带来的变化后面我们陆续会分享在研发过程集成架构等方面的思考。 SOA微服务云原生研发过程CMM/RUPAgileAgile交付流程手工/自动化DevSecOpsGitOps/AIOps/NoOps服务通信Web ServiceREST/专有RPC协议REST/gRPC等开放协议服务治理ESB微服务/API网关服务网格应用运行环境物理机/虚拟机虚拟机/容器Kubernetes/Serverless基础设施IDC公共云/私有云无边界的云多云/混合云 云边端
原文链接 本文为云栖社区原创内容未经允许不得转载。
