《企业IT架构转型之道》边读边想——共享服务中心的建设原则
发布时间：2022-09-12 16:19:03 所属栏目：大数据 来源：
导读： 概貌和说明
共享服务中心在阿里巴巴集团业务架构中的位置
1.活性演进的：服务中心一定是不断发展的
2.多样的：服务能力形式多样
（1）依赖于接口的服务(RPC、Web API)
共享服务中心在阿里巴巴集团业务架构中的位置
1.活性演进的：服务中心一定是不断发展的
2.多样的：服务能力形式多样
（1）依赖于接口的服务(RPC、Web API)
|
概貌和说明 共享服务中心在阿里巴巴集团业务架构中的位置 1.活性演进的：服务中心一定是不断发展的 2.多样的：服务能力形式多样 （1）依赖于接口的服务(RPC、Web API) （2）依赖于工具的服务 （3）依赖于数据的服务：对大数据的分析能力 3.可再划分的：服务中心是有划分的，且可以进一步划分的 共享服务的设计考虑和设计原则 一、考虑 不建议使用的标准：LOC(Line of Code) 大数据高并发系统架构_cio面临大数据架构的选择困境_大数据架构标准 设计层面：业务和系统建模主要是遵循面向对象的分析和设计方法 运营层面：应该是一个完整的业务模型，要有数据运营和业务整合的价值 工程层面：基于分布式架构的共享服务架构，解决了大规模应用的问题，也引入了分布式事务、问题排查等挑战 不能图一时之快把业务拆的太碎，到最后不得不用很大资源投入来解决技术上面对的问题 二、原则 高内聚、低耦合原则 耦合性分类(低――高)耦合程度 (越大越耦合)耦合性分类说明 0 无直接耦合 - 1 数据耦合 指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递 2 标记耦合 指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址 3 控制耦合 指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能 4 公共耦合 指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加 5 内容耦合 这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部 内聚性分类(低――高)内聚程度 (越大越内聚)内聚性分类说明 0 偶然内聚 指一个模块内的各处理元素之间没有任何联系 1 逻辑内聚 指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能 2 时间内聚 把需要同时执行的动作组合在一起形成的模块为时间内聚模块 3 通信内聚 指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据 4 顺序内聚 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入 5 功能内聚 这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的 遗留问题：如何结合业务演化界定拆分边界和粒度？ 遗留问题：如何量化衡量？ 数据完整性原则 该原则可以认为是将高内聚低耦合原则穿透到数据模型层面 服务化架构的一个很重要的业务价值就是数据模型的统一 大数据思维：不光是业务逻辑的关键数据，还包括业务的相关性数据；不光是业务实时在线数据，还要考虑到离线计算的数据 业务可运营性原则 我们期望服务中心是可运营的，是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。 业务的运营性的两个层面 沉淀阶段：当业务处于快速生长期，这时候的运营目标是满足上层的业务需求 创新阶段：运营业务内部孕育出来的创新想法 * 基于统一的数据模型大数据架构标准，低成本的引入大数据技术；让数据来源、数据分析、业务生产形成闭环 * 能否用大数据能力提升运营水平是服务中心原则之一 渐进性的建设原则 坑： 拆得过细，有延迟太长的问题 数据过于分散，有数据库性能的问题和分布式事务的问题，服务接口过于庞大的问题 服务化应该从简单开始，用真实的业务需求锤炼出稳定可靠的共享服务。 （编辑：草根网_连云港站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330470号