面对市场上的日益丰富的产品选型中,技术架构有多种,我接受了SOA和中台的产品,SOA的产品线是基于总线型的,在各应用系统之间, SOA 依靠 ESB 实现系统集成,ESB 是治理点对点式的系统集成的核心手段它肩负着如下重担
1.实现系统间的连通;
- 数据转换;
3 智能路由;
4安全控制;
5可靠性控制;
6服务管理;
7.服务与监控
SOA 针对医院业务系统架构的治理主要依赖于两个方面:一方面
立足千每个应用系统,要求系统对提供的“服务” 进行提炼和抽象, 确保其灵活、可重用,这
是让服务满足外部复杂需求的根本保障;另一方面是通过中心化的交互媒介一—ESB 来约束系
统间的交互,消除点对点式集成的负面影响。
但令人感慨的是:走到今天,回看医院曾经在SOA 上做出的
尝试和努力,最后的效果多数都不够理想。在完成SOA 改造之后的若干年间,受到后续各种新
系统的冲击,很多医院都没能坚守住自己的SOA 体系,最终又回到了烟肉架构下的野蛮生长状
态,这其中的原因主要是:
1.沟通与协作成本高:新系统迫千业务需求和市场压力,急需上线,对负责的团队而言, 与周边系统的对接和调试属于外部不可控因素,团队总是倾向千在内部可控的范围内解决问题,因此会刻意避开对外部服务的依赖,选择自建相关功能,这样一来,系统间的交互会向着衰减的方向发展,重复建设也因此随之蔓延;
2.组织架构制约:团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿,因为新系统与他们没有直接的利益关系,医院也缺乏适当的奖惩机制促使各团队之间的积极协作, 本质上,这是组织架构决定的;
3.缺乏长效机制:SOA 改造常常是作为一个项目实施的,项目结束之后就不再有专门的组织和团队对 SOA架构进行持续把控了,后续新的系统在融入 SOA 生态时受到的支持就减弱了,而新系统本身提供的服务也缺乏必要的梳理和管控,有的新系统甚至不对外提供服务。
后来发现提出来了数据中台
数据中台就是一个什么都能装的篮子,除了原有数据平台内的技术框架、应用场景、其它的或许跟大数据一点边的场景、数据内容、框架都会往里装,以及站在更高的组织结构上去思考数据的全局化、统一化、一致化的设计与实施,强调复用性、共享式的服务。
我们如果太依赖中台,产生这样的问题,中台为了做规模强制向业务线推行,业务线被迫削足适履,消耗严重。1.每次中台升级,小的 BU 更是叫苦不迭,故障频发 2.中台能力一旦发布, 独家专供, 哪怕功能不完善, 设计不合理也不允许业务团队复制或分支。3
我们面对这样的问题,如何做业务和产品的迭代,请专家给予讲解