架构设计篇之中台战略思想与落地

用户头像
小诚信驿站
关注
发布于: 2020 年 07 月 14 日
架构设计篇之中台战略思想与落地

前言



最大的浪费不是重复建设,而是不断重复建设。

--阿里巴巴集团中间件技术部研究员蒋小伟(小邪)

个人觉得蒋小伟老师说的非常有道理,所以这里引用该评价。



中台的决策

中台概念

  • 技术中台,比如微服务开发框架、Devops平台、PaaS平台,容器云之类的

  • 业务中台,比如用户中心,订单中心、商品中心、库存中心、交易中心等

  • 组织中台,比如企业内部资源调度中心和内部创新孵化组织等

  • 数据中台,比如数据模型中心,数据开发中心,数据存储中心,数据服务中心等



那么这里的所有概念都源于阿里的大中台,小前台的思想战略,然后引起了跟风热潮。那么回过头来看这里的概念中台更像是抽象出的一个个组件。如果是面向软件的视角来看,这些应该是组件化服务,也是蒋小伟老师提到的避免重复建设的工具。下面的共享业务事业部来源于《企业IT架构转型之道》阿里的中台战略架构图。



中台好处

针对公司组织架构,便会根据系统服务以及组织所涉及的业务来进行了定位,技术中台,业务中台,组织中台,数据中台。当然有的公司会根据不同的业务产品进行事业群划分比如腾讯,分为不同BG,比如企业发展事业群CDG包含大家熟知的广告营销之类,IEG互娱大家熟知的王者荣耀,吃鸡等,TEG相当于技术基础架构部提供主要的基础服务设施,WXG微信由于比较优秀所以单独的一个事业群,包含微信下的所有内容,CSIG主要发力于腾讯云与智慧产业赋能相关,PCG平台内容包含大家熟知的QQ,应用宝,微视等。

现在的技术正在逐步上云,大家也在齐心协力构建中台体系,统一技术设施。早期便是不同的业务BG维护不同的技术设施,快速响应需求和技术支持比较笨拙,内部数据封闭,协作问题难,导致被头条反超。



中台问题

上面举了一个腾讯的例子来阐述了中台的好处,那么中台的坏处又是什么呢?



由于大量的中台概念,服务化概念,云概念等词汇的频繁出现,导致大家的需求都在追求去中心化,就放佛很多年前,大家一拥而上使用SOA概念的ESB实现方式一样。明白的咽着苦水,不明白的跟着大公司走。



  • 业务架构师的能力问题

每个业务架构师对于中台的理解程度,以及自身的认知设计能力的不同,以及背后驱动的因素不同,涉及出的中台是否偏离原目标,没有人来评价。

  • 业务服务的需求与服务改造的动力不足

很多公司依然是以业务驱动技术,由于涉及到公司投入的成本和收益,中台能力的推动,后期诸多因素难以继续。

  • 中台能力搭建,服务数量和业务覆盖范围扩大

没有很好的基础设施建设和团队投入,导致中台搭建上下游依赖,基础建设依赖难以推动协作服务。

  • 服务拆分微服务,服务依赖与耦合错综复杂,人员离职交接文档不完善

没有好的技术文化建设,交接wiki等输出,后期重复建设,盲目接受需求,中台形而不实。

  • 服务的数据管控,服务的SLA保障,服务的治理

随着系统服务的增多,需要有服务全链路跟踪,方便快速定位问题,以及梳理服务之间的依赖关系,定位服务的性能瓶颈等。



小结一句话:中台需要自上而下的变革,以及后期不断的需求维护,以及基础建设维护持续更新。如果盲目中台化战略实施,很容易后期后劲不足,中台战略失败,浪费人力,财力,物力。投入和收益不成正比。



但是从长期长远来看,如果公司希望后期快速应对变化,拥抱变化,则中台战略势在必行。

否则会经常面临如下的服务问题:

  • 项目团队间协同成本高,业务响应越来越慢

  • 应用复杂度超过人的认知负载

  • 错误难以隔离

  • 数据库连接能力很难扩展(比如太多的应用机器,需要数据库连接,有限的链接池的瓶颈)

  • 应用扩展成本高



中台的建设

领域边界服务化

  • 划清业务边界,制定领域模型

比如该业务是订单中心,该业务是商品中心,该业务是用户中心,根据不同的领域划分不同领域模型。

  • 回归SOA的本质,服务重用原则

领域边界服务化一定是面向SOA的,底线的原则是减少不断重复建设,那么我们需要提炼公共服务,尽最大化提高服务重用性。

  • 拥抱变化

领域服务是跟随业务需求不断变化,而不断完善的,互相影响,如果需求已经不满足,迭代效率差,那么可能是该领域服务退役的时候。

领域服务治理化

  • 约定服务最小原则,也就是微服务化的粒度

1、观察自己的投入和产出

比如服务化改造,自己需要投入的成本人力和时间周期,以及改动的范围,定义服务化改造标准衡量值。

2、根据自己的业务划分,一切离不开业务

比如自己负责的统一对外开放能力,则定位开放平台。比如自己负责的用户权限管理,身份白名单等,则定位为用户平台。

  • 约定提供的服务能力

比如技术中台:底层Paas的能力,解决大型架构在分布式,可靠性,可用性,容错,监控,以及运维层面上的通用需求。

比如业务中台:提供云化的核心业务支撑能力,决定是否能真正支持上层业务达到敏捷,稳定,高效。

针对自己的服务能力进行定位和约定。

  • 服务平台化

搭建服务平台,比如用户中心要演变为用户平台,交易中心演变为交易平台等,提供平台化能力的支撑。

1、确定自己的服务化对象

2、建立共享服务的基础设施

服务的描述元数据

  • 服务注册与发现机制

  • 服务的访问控制与安全策略

  • 应用服务Portal

  • 服务依赖与运维管理

  • 服务SLA协议

  • 服务消费者的管理与支持工具

  • 服务化辅助工具支持

  • 服务调用分析与报表

  • 服务成本核算与服务能力变现

  • 文档与开发工具支持

  • 领域服务产品化

    • 服务的稳定化

    服务的上下游依赖调用,对于服务的稳定性要求会越来越高,提升服务的稳定性,监控告警平台,分布式日志平台,全链路跟踪平台,故障定位分析平台,限流降级平台。通过各种平台来保障自己的产品服务具有稳定性,高可靠性。

    

    • 服务的可视化

    服务的UI界面管理,服务的可视化管理,帮助研发或者运营能够更好的,更直观的看出问题,以及看到资源使用情况,以及流量分配调度,实时数据流,实时交易等。比如阿里或者京东的双11或者618的大促监控盘。

    

    • 服务的共享化

    服务的共享能力决定了服务的未来长远走向。

    

    服务共享原则:

    1、要找到一个合适的服务化对象

    涵盖业务流程,数据服务能力,便于实现对对象的服务化组件封装。

    2、建设对象服务化的基础设施

    服务治理工具与平台,服务化对象封装成服务组件,完成治理。

    3、服务化实施阶段

    用服务化基础设施把服务化编程服务组件,让业务方共同参与进来推动业务服务化,享受服务化带来的应用服务治理的红利。

    4、增强服务和基础设施实现服务的精细治理

    通过产品和工具的支持,为用户提供更好理解,更易用,更优质的服务,最终达到按需服务的层次。

    

    领域服务商业化

    • 服务的运营化

    数字化运营能力,提供产业互联网的可运营能力。

    • 服务的场景化

    对于产品服务的业务场景,进行针对性的展示和梳理。

    • 服务的解决方案化

    对于服务的不同业务场景有着不同的场景解决方案能力,对于未有的业务场景,也能提供快速的响应解决方案。

    

    小结

    一切源于业务需求,一切终止于业务需求,以需求为始。

    

    发布于: 2020 年 07 月 14 日 阅读数: 431
    用户头像

    小诚信驿站

    关注

    小胜靠智,大胜靠德 2019.06.27 加入

    历经创业、京东、腾讯、滴滴公司,希望能够有些东西一起分享。公众号:小诚信驿站,微信/CSDN搜索:wolf_love666

    评论

    发布
    暂无评论
    架构设计篇之中台战略思想与落地