$恒生电子(SH600570)$
分布式是个被广泛普及的理念，但在具体落地时，涉及的不仅仅是技术，与管理体系、能力也有非常密切的关系。下面这篇文章，写的很不错。
雪球的评论帖子，连空行都无法实现。可能是想逼你发新帖，这是一家不善的公司。
恒生首席科学家白硕 ：也谈“松耦合” 2023-03-01
当下，“松耦合”成为一个出镜频率很高的词。作为技术人，我们都知道松耦合是对系统架构的一种诉求，即各个子系统/组件之间的接口尽量精简、明晰、标准化，以便于单个子系统的独立调优、升级、乃至更换，而不影响其他子系统和整个上级系统正常工作。恒生电子是松耦合架构的积极倡导者和实践者。恒生自身的产品，多年来一直在不断探索和优化最符合用户利益的合理架构原则。我们深知，松耦合这个理想虽然是很丰满的，但实践的时候，也要注意现实的骨感，注意松耦合对IT治理能力的反向要求，注意松耦合与企业内部部门设置和流程同步推进要求。把“松耦合”当成道义制高点说事儿，更是一种需要防范的“技术蒙汗药”。松耦合绝不仅仅是架构问题
松耦合是技术架构层面的解耦。要做到在技术架构层面解耦，就意味着在更高层面必须有更强的掌控。这里面的“强掌控”，包括了以下五个方面：
对接口标准的掌控。由于实行了松耦合，接口就是子系统/组件间互操作的唯一规范。站在全局的视角，对子系统/组件之间的全部互操作格式进行定义或重定义在所难免。这是一项浩大的工程，不仅涉及技术领域，也涉及到了业务领域。因此，拥抱松耦合，必须标准先行。而标准的制定，必须从一开始就充分吸收业务领域的意见和建议，尊重业务领域的现状和规划。这方面如果准备不足，可能会遭遇颠覆性的挫折。对技术底座的掌控。松耦合是以技术底座的支撑为前提的。实现业务逻辑与基础设施/共性技术服务之间的松耦合，是松耦合的应有之义，而这又必定会提出对统一的技术底座的强烈需求，其中包括资源调配/共享/监控、消息通信、任务编排、分布式高可用等一系列诉求。在目前情况下，只有云原生底座才能有效地支撑这些需求。所以，对技术底座的掌控力尤其是对云原生底座的掌控力如果尚未就绪，松耦合还是要慎行。对软件质量的掌控。松耦合意味着开发过程在一定程度上的“去中心化”。而由管理理念、质保措施、员工素质各异的若干个不同独立法人主体治下的研发团队开发出来的子系统/组件能否放在一起有效地、合乎预期地协同工作，是跟统一的品控措施分不开的。在化妆品、奢侈品等行业，知名品牌之所以知名，跟卓有成效的统一品控有着密不可分的关系，这点可以为我们行业所借鉴。所以，松耦合是好经，会不会被念歪了，很大程度上取决于业主的统一品控能力。对开发成本的掌控。熟知系统论的朋友都知道，系统大于部分之和。同样的逻辑可以得出，系统开发的总成本大于子系统/组件开发成本之和。这多出来的部分，就是在总体层面进行规划、沟通协调、解决跨子系统/跨组件问题、实施跨子系统/跨组件的各类测试联调的开销。如果各子系统/组件的开发任务由不同独立法人主体治下的研发团队承担，那就要在开发总成本的测算中充分预计规划、沟通协调、问题解决和测试联调的难度。如果得不偿失，松耦合不做也罢。对运维协同的掌控。在核心关键系统的运维中，跨服务商定位运行异常问题，一直是很容易引起扯皮的部位。系统越松耦合，卷入问题的服务商越多，在松耦合架构下的取证和根因分析就越困难，运行异常问题的定位复杂度就越高。这里，取证基础工具应该与松耦合架构同步规划，运行异常的责任归属问题也应该同步明确约定。这方面的准备工作如果没有做好，等到出了问题再进行跨服务商协调，工作局面将会极其被动。综上所述，松耦合绝不仅仅是架构问题。它牵一发动全身，涉及到业务与技术的关系问题、底座与应用的关系问题、分布式开发与集中化品控的关系问题、开发成本与集成成本的平衡问题以及各子系统/组件及其供应商的责任边界问题。对这些问题如果不是事先有所预案，势必导致松耦合改造走样、变形乃至功败垂成。从松耦合意味着企业内部部门设置和流程的重构
松耦合，就一定会有相应的中间性技术资源/数据资源按照标准接口释放出来，比如特定的微服务、特定的业务组件和特定的数据指标/标签等，以便于后续的复用。复用技术资源可以提高开发效率，但也很有可能引发部门间的问题，比如业务边界问题、数据和流程权限问题、合规问题、事故责任问题等等。一般来说，企业数字化基础设施的架构发生重大变化，总是和企业的治理架构同步进行的，总是伴随着流程、部门和职能的重大调整相联系的。首先是业务边界问题。一项工作总要有相应的责任方，也就是owner。在松耦合架构下，“工作”需要细粒度分解，比如，每一个微服务或组件，每一项指标或标签，都要有相应的owner。如果不能按照这样的粒度拆分和定义业务边界，就会出现盲点和误区，最后免不了要由技术部门来兜不该兜的底。其次是数据和流程权限的问题。有了业务边界的清晰定义，就可以在此基础上划分数据和流程的权限，只让合适的人和子系统/组件访问合适的资源。监管对一些机构还有内部隔离墙的要求。从合规角度考虑，隔离墙在松耦合后的企业IT架构中也必须有相应的落地安排。权限问题，事关企业内部资源“拉通”之后的安全，而对安全后果的判断，不能只孤立地看单项数据或服务，更要看多项数据或服务融合后可能产生的“化学反应”是否会造成安全后果，这需要更加专业化的判断，需要安全与数据和业务的深度融合。当然，过度的安全措施也会不必要地破坏用户体验，也要防止。在松耦合架构下，子系统/组件间可能的相互作用路径增多，事故和系统异常的传导路径随之增多，于是事故责任的判断较之单体系统而言增加复杂性。在企业内部应急预案制定、应急演练开展和应急资源安排上，都要做出与松耦合架构相适应的调整。松耦合架构不会自动‘破除垄断’
数字化转型是一项长期的工作，也是一段时期内企业可能会投入较多资源的工作。金融机构不可能所有子系统/组件全部自研，一定有相当一批子系统/组件和服务需要从外部采购。松耦合架构的采用，会对金融机构的采购工作和供应商关系管理工作产生一定的影响，但是任意夸大这种影响，也会把金融机构带入新的“误区”。比如，有人企图把采用松耦合架构，跟所谓“破除垄断”画等号。我们认为，松耦合架构并不保证自动“破除垄断”。一方面，如前所述，在松耦合架构下子系统/组件的“八国联军”格局更不利于企业的根本利益；另一方面，接口标准、品控标准和技术底座的掌控方如不是企业自己，那很可能会引入“变相垄断”。这种把是否采用松耦合架构跟“破除垄断”强捆绑的说法，其实是一种话术，意在通过接口标准、品控标准和技术底座等引入“变相垄断”，不得不防。只有企业自己把对松耦合架构的掌控力做强，才能顺利实现用松耦合架构支持业务发展的目标。数字化转型是一项艰巨复杂的工作，有天地广阔的蓝海有待我们去开拓。采用松耦合架构是趋势，但不是教条。以正确的姿势拥抱松耦合架构，是数字化转型路上的一大考验。恒生在对自身产品进行适度的松耦合架构升级的同时，也将全力帮助金融机构把对松耦合架构的掌控力做强，和广大行业同仁一道，满怀信心地应对这场考验的挑战。