美文网首页中台战略中台
《中台战略》- Chapter 6 - 6.1 技术中台规划

《中台战略》- Chapter 6 - 6.1 技术中台规划

作者: 复苏的兵马俑 | 来源:发表于2020-02-29 16:28 被阅读0次

    推荐购买《中台战略-中台建设与数字商业》正版纸质书籍阅读

    6.1 技术中台规划

      技术中台主要包括基础设施层、技术PaaS层和业务中台的基础组件层。
      1)基础设施层主要是云化的基础实施资源,包括共享的云存储、共享的计算资源等。
      2)技术PaaS主要是指互联网技术中间件,如常见的分布式应用服务、容器服务、消息服务、服务注册发现、容器管理服务、日志服务等,为我们的应用软件提供运行环境。
      3)基础组件是指从业务中台抽象出来的通用技术功能模块,既包括认证、消息发送、规则引擎等,也包括为了隔离技术PaaS的复杂和异构而设计的适配器,比如消息队列的适配器、缓存的适配器等。

    6.2 业务中台的建设
    6.2.1 建模抽象机制

      从业务到中台,必须经历抽象建模的过程。这个过程分为两个阶段,分别是0级抽象中心建模的阶段和1级抽象组件建模的阶段。每个阶段采用的建模抽象机制都是实体抽象法。

    功能需求汇总表

      下面以0级阶段建模抽象为例进行说明:
      首先,我们梳理出企业功能需求;
      其次,找出每一个功能需求所对应的业务对象或实体。实体分为两类:业务实体(叫“静态实体”更容易理解)和过程实体;
      最后,根据能力的主题、实体的密切关系,定义出主题域(也可以称为“业务域”)。

    功能需求抽象表

      划分出多个主题域后,技术架构师需要结合技术的实现,将领域进行组合规划出中心。中心的划分标准主要从实体的聚合度、中心的职责、中心颗粒度、能否独立运营等方面来权衡。确定中心的过程也就是划定功能边界的过程。

    某企业的中心划分结果

    6.2.2 业务中台的8个设计原则

      业务中台是一个充满生命力的个体,它承载业务逻辑、沉淀业务数据、产生业务价值,并随着业务不断发展进化。它的设计遵循如下8个原则:

    业务中台设计的8大原则

      1、服务松耦合原则
      1)面向接口实现:这是服务松耦合的基本要求,即每一个服务都按接口的定义进行实现。服务的消费方不需要依赖某个特定的服务实现,避免服务提供方的内部变更影响到消费方。另外,在服务提供方切换到其他系统时,不影响服务消费方的正常运行。
      2)异步事件解耦:服务间的事件通信采用异步消息队列来实现。由于有消息队列这个中介,因此生产者和消费者不必在同一时间都保持实时处理能力,而且消费生产者也不需要马上等到回复。
      3)服务提供者位置解耦:服务消费者不需要直接了解服务提供者的具体位置信息,例如IP地址、端口。典型解决方法是服务注册中心,服务提供者启动时将自己注册到服务注册中心,服务消费者通过服务注册中心查找具体服务提供者来访问。同时,服务注册中心可以提供负载均衡及fail-over的能力。
      4)版本松耦合:消费端不需要依赖服务契约的某个特定版本来工作,这就要求服务契约在升级时尽可能提供向下兼容性。

      2、服务依赖原则
      1)有价值的领域模型
      价值导向:确保业务中心的服务都与企业的商业理想保持一致,相关联。
      简捷为美:业务逻辑和流程避免复杂化。
      领域洞察:紧贴业务的核心目的,从业务原则指导业务逻辑的设计。
      2)服务间最小依赖
      高内聚:同一类服务应归在一起。
      低耦合:服务间保持最小联系。
      能力与接口:业务流程和业务逻辑的操作都作为中心服务实现,而提供给外部调用的接口数据模型都会转化为服务。
      识别通用性:识别出每个通用能力的可扩展的类型,从设计上支持它不断扩展,并在接口定义上满足其不断升级的需求。
      3)能力实体具有层次性
      能力与接口:分离接口实体与能力实体。
      接口实体与限定元素:将接口实体核心元素与接口操作的限定元素分离。
      接口实体的层次结构:建设接口实体和上下文限定元素的层次结构。
      4)延迟对技术组件的依赖
      捆绑依赖:避免在无关的技术组件之间引入新的依赖。
      延迟绑定:在使用点才捆绑依赖关系。

      3、服务设计原则
      1)优化远程调用:服务间的远程调用分为同步调用和异步调用两种模式。应当分析服务调用场景,选择较优的调用模式。
      2)去掉冗余数据:尽量去掉接口实体中客户端不需要的冗余字段,既能减少网络开销,又能避免给前端解析带去复杂性。
      3)设计粗粒度的服务接口:服务接口若能与前端一个用例或一个业务场景相对应(粒度较粗),则既能减少远程调用次数,又能降低学习成本。
      4)识别并设计通用的服务接口:由于中心服务不限定应用范围,因此一般要支持不同的应用。但不同应用在功能丰富性上有很大差异,这就决定了服务接口需要尽可能保证广泛兼容性。譬如,服务接口的参数和返回值必须是被广泛支持的较简单的数据类型。
      5)隔离服务内部的变化:避免服务内部的领域模型直接传导给客户端。如未能提供合理的隔离措施,则当服务进行内部重构时,势必导致客户端频繁变化。
      6)服务接口先行:详细规定服务与客户端双方对接的内容与形式等,对双方形成强有力的约束和保障。
      7)服务接口向下兼容:由于应用的广泛性,在服务公开发布之后就要保证相当的稳定性,不能随便重构,即使升级也要尽可能考虑向下兼容性。

      4、服务命名原则
      强烈建议使用服务使用者专业领域内有意义的名称,优先选用业务概念而不是技术概念。
      使用名词命名服务,使用动词命名操作。

      5、服务颗粒度原则
      服务应是内聚而完整的,能够独立完成一个职责。在服务内部可以是由多个逻辑上密切相关的代码块共同组成。

      6、服务的无状态性原则
      微服务体系的基本要求是服务无状态。无状态的服务是可伸缩、高可用性的基础。

      7、服务操作设计原则
      操作表示业务动作,应当使用具体的业务含义而不是泛型操作来定义操作。相关的最佳实践如下:

    • 重要的服务不能依赖非重要服务。
    • 任何服务调用都要设定超时时间。
    • 任何服务的调用结果只有三种可能:成功、失败或未知。
    • 能异步调用的服务尽量使用异步调用,从而提高系统响应速度,降低系统之间的耦合性。
    • 系统拆分时,粒度大小以一个系统3~8个开发人员维护为宜。
    • 系统拆分时,往往先拆分数据服务层,因为数据服务层通常是复用性高的一层。
    • 服务的实现不能有单点。
    • 线上遵循fast-fail原则,避免服务调用时间过长,导致性能下降。fast-fail原则是只要发生错误,则调用立即返回。
    • 需要对高压场景下的服务调用链路进行特殊处理,可采用将链路缩短、预热等方式。
    • 服务设计过程中,要避免同类服务由不同服务单元提供。
    • 服务要做到向后兼容,如果无法做到,则需要采取管控机制确保服务消费者升级服务。
    • 服务化架构的变化要使组织的架构能适应这种变化。
    • 在部署服务单元时,要将读服务和写服务分离,将核心服务和非核心服务分离,以保证整个服务单元的稳定性和可靠性。
    • 服务化时,要同时考虑安全。
    • 静态资源也可以实现服务化,实现静态资源与动态资源分离,从而提高性能。
    • 通过在外层系统埋点,可以实现面向终端用户服务的精细管理,比如服务的容量、服务的性能等。
    • 需要将每个业务领域的通用规则沉淀成服务。

      8、服务约束原则

    • 上可依赖下;
    • 下不可依赖上;
    • 上可跨级依赖下;
    • 平级可允许单向调用,坚决禁止循环依赖;
    • 高级别不可依赖低级别;
    • 简单就是美;
    • 重要的服务不能依赖非重要服务。

    6.2.3 分布式运行机制

      中台采用微服务风格进行建设,每一个业务中心都是独立部署的,因此分布式运行机制是保障业务中台正常运行的基础。

      1、服务注册与发现
      服务注册是服务发现机制的核心,服务实例将自己的服务信息(包括网络IP、端口、服务名)注册到服务注册中心,服务注册中心将服务信息以及服务健康状态通过API暴露出来。

      2、弹性伸缩
      在分布式集群里通过服务探针,可以监控应用和服务容器的状态,自动调整服务实例的数量。扩容,在监控到服务容器出现瓶颈,包括负载、CPU、RT指标都出现紧张时,能够自动增加应用实例到集群中。缩容,在监控到服务容器负载减少出现资源浪费时,自动释放服务实例减少成本。调整弹性伸缩的规则支持用户灵活配置。

      3、限流降级
      分布式应用服务需要提供限流功能,时刻感知流量的变化,并做出相应调整。限流的策略可分为限制访问的绝对数量和控制流速(整流)。整流的算法有令牌桶算法,限制总数可通过设置规则来实现。
      降级是指某个服务被调低级别后,本服务的消费者在调用时即刻返回失败,这样服务实例将不会被调用。当然,也可以设置一个默认返回值。降级的规则支持用户灵活配置。

      4、灰度发布
      灰度发布的技术用于两个不同版本同时在线上并行的情形,既可用于业务试错,也可用于版本发布。一旦确认新版本达到目的,就可以平滑地从旧版本切换到新版本上。灰度发布需要解决两个方面的问题,才能顺利达成目的。
      1)多版本部署:多版本部署分为客户端部署和服务端部署两个方面。客户端如果是原生系统,可以用热更新技术实现,比如Android的CodePush。客户端如果是H5,则需要在服务器端部署一套CSS和页面。服务端部署要求应用服务、中台服务都要单独部署一套,通过版本来区分。如果需要对MQ的数据消费进行隔离,则需要重新定义Topic或Tag。
      2)流量切分:流量切分包括入口流量切分和中台服务流量切分。入口流量的切分策略通常包括按服务器权重、IP地址段或用户标签等来切分流量。中台服务流量切分通过分布式服务发现机制,植入流量切分规则,控制流量的方向。

      5、消息队列服务
      消息队列服务是互联网应用场景下非常重要的一个技术中间件。在业务上,通过消息队列既可以提高用户体验,又可以支撑IM业务等;在技术上既可以解耦系统,又可以削峰填谷等。消息队列具有高性能、高可用、最终一致性等技术特点,是技术架构的重要组成部分。
      1)异步通信:消息发送方将耗时较长且无须实时处理的操作封装为消息,发送给消息队列服务。发送方无须等待消息被消费方处理完成,可以继续做其他事情。消费方则可以按自己的节奏完成消息的消费。异步通信可用于系统间的解耦,各系统独立自主,互不影响;也可用于减少请求响应时间,提升用户体验。
      2)高可用:消息队列服务以集群的方式部署,常见的有1主多备或2主2备等。消息服务接收到消息后,会同时分发给多个备份服务各自创建一个备份。当一台消息队列服务挂掉后,另一台消息备份服务可以无缝对接,及时提供服务。在RPC调用方面,提供了负载均衡、服务注册与发现功能,保证了消息队列服务在高并发场景下的高可用。
      3)高可靠:消息队列服务提供了极高的可靠性,不过应用开发时还需要统一提供retry机制,进一步提高可靠性,降低应用开发的复杂性。消息队列服务在收到消息后,会立即执行消息的持久化处理。比较常见的持久化方式包括存储到文件和存储到数据库两种。持久化机制包括同步双写和异步复制,保证了数据的高可靠性。
      4)基于消息的最终一致性:使用半消息技术,保证只要一个事件发生后,关联的结果事件一定会发生。半消息解决了如下问题:

    • 事件发生后,事件消息发送却失败;
    • 事件消息发送成功后,消息代理推送给消息消费方却失败;
    • 消费方重复消费此消息。

      6、分布式事务
      分布式事务技术(DTP)用于保证跨多个资源事务的一致性,目前X/Open XA标准已由众多厂家实现来支持分布式事务。DTP模型的典型应用场景是两阶段提交协议,多个资源管理器(RM)由一个事务管理器(TM)进行管理,事务管理器控制着全局事务和分支事务。DTP模型分别通过准备阶段和提交阶段来协作完成全局事务:准备阶段,由TM通知各RM准备事务,并接收RM的准备结果;提交阶段,由TM通知各RM提交分支事务,并接收RM的执行结果。RM执行结果都成功,那么TM返回成功,如果任意一个RM执行失败,原则上TM都会执行回滚。但在实践过程中,RM失败的情况也有不同,TM可按照客户的需要判定是否回滚所有事务。

    6.2.4 扩展点机制

      业务中台自身提供了很多配置化功能,支持灵活快速地对业务功能进行扩展。除此之外,扩展点机制提供在不修改现有代码的情况下,灵活扩展新功能。扩展点机制源于Java的SPI机制,当业务中台的某一个业务点遇到新业务逻辑比当前逻辑差别较大时,可以使用扩展点机制来实现。

    相关文章

      网友评论

        本文标题:《中台战略》- Chapter 6 - 6.1 技术中台规划

        本文链接:https://www.haomeiwen.com/subject/wxqhchtx.html