SOA从试点到普及,我们还需要什么?

本文探讨了SOA项目的实施与治理问题,强调了SOA不仅是技术应用,更是一种思维方式的转变,需要通过有效的治理机制来确保其成功落地。

前些天与几个朋友一块吃饭,席间一番对生活的感慨之后,大家最终还是免不了“俗”,话题还是回到了当下疯狂的股市和热闹的SOA。一位朋友问了我一个问题:“到底什么样是你说的SOA?是不是我的应用遵循了松耦合的设计思想,采用了所谓的ESB产品,部署了几十个WebService,就应该算是成功的SOA了呢?”。事实上,类似的问题最近不断有人问起,这反映了人们一种再正常不过的思维。几乎所有的SOA实施者都在迫切地想要找到一种方式,能够给SOA项目贴上一个简明的标签,告诉C-Level和各条业务线的大脑袋们:“嘿,看看,哥们这事成了”。坦率地说,我当下脑子里的第一反应是Yes,但酒精下残留的一点“专业精神”,让我觉得有必要多一个角度来回答。

 如果是一个SOA的试点项目,不管是从业务线切入还是IT线切入,只要采用SOA的技术思维,切实解决了当下的问题或是应对了未来的挑战,这就是一个SOA很好的落地。我们鼓励,大道从简,在试点阶段以尽可能简单明确的目标来快速证明SOA的价值。我们目前所看到的SOA项目,绝大多数都是这样的试点,在一个业务线内部或在核心应用周边,小规模地遵循SOA的设计理念,采用SOA的工具帮助使能或构建服务,解耦和管理服务。事实上,这种努力大部分已经取得了成功。毫无疑问,从这个意义上来说,对上述问题的回答是YES。与此同时,我们也需要看到,SOA的目标是创建可重用的服务,这些服务可以在整个企业内不同业务线的应用系统中使用。仅仅在一个小规模范围内试用,并不能获得SOA所承诺的于IT和Business更经济划算、更敏捷响应的全部价值。从这个意义上来说,对上述问题的回答是NO。我们还需要在“速效”之后,冷静思考到底SOA的内涵是什么?更为重要的是当我们推动SOA从试点到大规模普及,真正还需要什么?

 本质上,SOA与其说是一种技术,不如说是一种思维方式,它表达了一种对业务和IT更密切结合的演化的认知。简而言之,SOA代表了一种更大范围重用的文化,而不是技术本身。就像过去,我们构建应用往往是为了满足某些特定的业务需求。事实上,这些应用也包含大量的构件或服务,可以在应用内部多处使用,但这些构件或服务很少会为外部应用重用去设计,与此同时其它业务线也很少会想到去重用这些已经存在的服务,而宁愿重新发明。事实证明,仅仅技术上的努力并不能换来大规模的重用,从而实现IT灵活和业务敏捷的目标。因此,企业必须明确地认识到,SOA决不是简单的技术采用,或是在市场上买到的什么产品,真正重要的是如何在整个企业内正确地实施这种文化。而推动这种文化变革,需要一套有效的治理机制。Gartner就曾指出,2006年从试点到大规模普及过程中,80%的SOA大中型项目(超过50个服务)将因为缺乏有效的治理机制而最终失败。

 那么,到底什么是治理(Governance)?简单来说,治理就是通过推行一系列的政策来鼓励希望看到的行为,获得期望的结果。就像近期央行针对当下的经济过热和疯狂的股市,连续出台了一系列货币政策,包括提高存款准备金利率,提高一年期存款基本利率,减征利息税等,来控制流动性过剩问题,来引导货币信贷和投资的合理健康增长。SOA治理也类似,就是通过建立的一个权责框架,来鼓励对软件资产的重用,帮助实现SOA价值。它不仅仅是帮助企业实施SOA,更重要的是指导企业如何正确地实施SOA。一个灵活而有效的SOA治理框架,应至少解决三个方面的问题:

 

首先,也是最重要的,组织需要首先明确自己的目标,也就是什么是自己所期望得到的结果。举例来说,我接触过一个政府机构。他们实施SOA的首要目标就是让各司局机关能够更有效率的协作,使得广大市民和企业从业者能够更容易、更透明地获得政府的信息和服务。同时,能够通过SOA实施改变长久以来因多头管理、地域差异等造成的刚性IT投资模式,使IT部门能够更快、更灵活地响应变化。

其次,要建立一套有效的治理机制,包括策略、流程以及与之相适应的组织结构,关键是要清晰地回答:“为了有效的管理,需要做出哪些决定,谁有权就决定提供输入,谁有权做出这些决定,怎样做出这些决定,如何推行这些决定,谁对决定的推行负责”。其中,策略是治理机制的基础。简而言之,策略就是帮助组织确定什么是对的,什么是企业所鼓励的行为。举例来说,一个最容易理解的策略:“如果服务已经在那里,不要重新发明”。试想一下,就算这样一个简单的策略被推行,企业将减少多少重复劳动,并可能因此改变工作的方式,改变对架构的理解,改变项目投资的优先级。同时,治理机制必须是灵活的,一方面要与整个企业SOA成熟度相适应,另一方面要能够根据实际运行过程中的度量反馈,持续改进。

最后,要定义一系列绩效度量指标,帮助了解现有治理模型的情况,确保实际在遵从期望的目标运行。最直接的例子,度量可以帮助我们了解“到底我们创建了多少共享的服务,每个服务被多少次重用,因为重用带来了多少成本的降低”等等。同时,度量也可以帮助我们发现当前遇到的问题和可能发生的趋势,比如某个策略可能需要调整,组织中某个角色需要重新授权等等。没有度量,我们很难说治理机制是否正确地被执行。因为如果连现在到了哪都不知道,我们永远无法达到目的地。

 到此,我希望已经能够回应了朋友的问题:个别的项目和应用的成功交付可以帮助企业走上SOA变革之路,并收获经验和信心。但是,当我们推动SOA从试点到普及,我们更需要文化的变革,需要一个灵活而有效的SOA治理框架。没有SOA治理,我们可能只是仅仅堆砌了一组Web服务和技术工具,无法实现SOA的全部价值。

 
内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
评论 10
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值