技术学习永不止步，最近也是看了很多关于架构设计相关的专栏，慢慢总结出来一部分知识，代入自己的思考与理解，以及结合并反思自己之前公司的架构设计经验，发现很多方法论适用场景，也希望能够解决小伙伴们的一些疑惑以及感谢大佬们也给我指点迷津，站在巨人的肩膀上成长~
复用性
首先谈一下复用性的理解：
复用性是指在系统设计和开发过程中，通过抽象和模块化设计，将通用的功能和逻辑提取出来，以便在多个不同的业务场景或技术场景中重复使用。
结合日程工作中我们能够接触的复用场景会更清晰的理解，并且可以快速切入后续中台的定义，从小到大，比如：代码复用—技术组件复用—业务实体复用—业务流程复用—产品复用
意义：复用性是系统设计中的重要原则，通过技术复用和业务复用，可以提高开发效率，降低开发成本，确保系统和业务的一致性和稳定性。
中台定义
中台核心定义：企业级能力复用平台，简单直接明确定义，也符合这篇文章的主题。
下面分别拆分阐述一下这个定义：
企业级：定义中台的范围；企业级侧重说明中台处理的问题在于企业级别，即至少多条业务线或者服务多个前台产品；
因此，中台建设>中台建设，一定需要跳出单条业务线，站在企业整体视角来审视业务全景，区分开了单系统的服务化与微服务；能力：定义中台主要承载的对象；不同企业的中台能力均不相同，可以满足用户不同层面的需求，即差异化竞争力；复用:定义中台的核心价值；复用，是中台更加关注的目标，也是业务驱动和用户驱动的；- 中台的衡量标准
“可复用性”和“易复用性”是衡量中台建设>中台建设好坏的重要指标；
“业务响应力”和“业务满意度”是考核中台建设>中台建设进度的重要标准。
用一张图解释一下，前台、后台、中台之间协调关系：
- 前台（Small Front Platform）是指直接面向用户的具体业务应用（面向C端应用，比如：微信、淘宝等），通常是轻量级的、灵活的、快速迭代的。前台业务应用主要负责与用户交互，提供具体的业务功能。
从开发角度可以将其理解为“前端应用服务+后端应用服务”，即不仅仅指前端，还包含与前端配套的服务端； - 后台：企业内部系统，比如ERP、CRM、仓库管理系统等，主要面向企业内部人员使用。
从上面的图中可以清晰看到前台需要快速响应，而后台企业内部流程基本不变，稳定不需要随意调整。
- 中台建设>中台建设，根本上是为了解决企业响应力困境， 通过对后台内部基础设施的包装，为前台提供全方位的支持；
- 中台建设>中台建设，提供一个中间层来适配前台与后台的配速问题，打通并顺滑链接前台需求与后台资源，帮助企业从整体上不断提升用户响应力。
- 中台建设>中台建设，不仅仅是前后台之间简单的适配器，中台本身也会有业务数据，完整的业务规则；与此同时，中台与前台构成C端业务的小闭环，支持业务的快速创新，等待业务模式验证后，中台与后台彻底打通，构成业务的大闭环；
深思中台建设>中台建设
从复用性角度理解中台，可能会更直接一点，最简单的就是日常开发过程中代码的抽象设计思维，只不过从更高层面理解。
哪什么时候考虑落地中台建设>中台建设呢？从上面的中台的定义也可以清晰表明，中台要基于多条产品业务线抽象设计。
故随着企业业务从0到1再到N条业务线时，则需要考虑中台建设>中台建设。但是此过程中，我们最好能够在设计中保持SOLID原则，也为了方便后期服务治理，这是面对公司从初始开始，但是面对已经有N条业务线的企业，则另当别论啦~
产品线形态
一、川字型结构
独立地建设新业务线，构成川字型结构；
这种结构比较常见，企业N条业务产品线，各干各的业务，重复建设业务功能，系统间大量的代码复制，浪费资源；
二、山字型结构
将各个业务线中相同的核心逻辑抽取出来，通过抽象设计，实现通用化，共同服务于所有业务线的需求，构成山字型
说明：
山”字型的上面三竖，代表各个业务线定制的应用；
最底下一横，代表通用层，它把各个业务线有机粘合在一起，实现了业务逻辑和业务规则的统一。
优点：达到一处建设，多处复用，一处修改，多出变化，高程度复用。
何时演变
即何时从川字型转变成山字型？？？主要从以下方面考虑：
- 业务线的数量：业务线越多，意味着重复建设的成本会更大，故
第三条业务线，开始考虑抽象设计； - 业务线的相似度：相似度越高，意味着业务线之间有更多类似的逻辑；
中台能力
中台通过实现基础业务的平台化，实现了企业级业务能力的快速复用。
-
变化速度：企业基础业务相对固定，具体上层业务场景相对多变的
-
数量：基础业务数量有限，具体上层业务场景是无限的
中台的建设，可以通过有限而比较固定的基础业务，来满足无限而快速变化的上层业务场景。 -
业务角度：中台收敛了业务场景，统一了业务规则
-
系统角度：中台统一对外提供标准的接口，屏蔽底层服务的复杂性
-
数据角度：中台收敛数据，统一使用相同的数据模型以及数据库存储
落地中台
经过之前的学习理解，概述：梳理企业目前现有的业务线，依据领域驱动原则，拆分功能模块，聚合领域服务（即微服务或者基础服务），最终形成平台化服务；
中台建设>中台建设，需要建立在微服务设计的基础上，故引发思考，如何将现有单体服务逐步拆分成微服务设计呢？？？？
以电商平台为例，在微服务架构下，我们拆分出订单服务、商品服务、库存服务等；而在中台建设>中台建设中，会将这些微服务升级为订单中心、商品中心、库存中心等；
升级前后的区别：
- 服务中心更强调体系化：业务通用能力、系统运营能力、业务运营能力；
- 服务中心围绕自身核心业务，自成体系、业务内聚，成为一个微内核；
典型的业务中台架构图如下：
- 通用聚合服务：对基础业务进行组合，提升业务能力的易用性（可以将其理解为BFF层）；
- 通用基础业务平台：基础的业务能力实现；
- 通用中间件平台：通过技术手段保证业务中台的稳定性
总之，中台是微服务的升级。即松散的微服务—>共享服务体系—>中台。
业务中台架构
典型的企业中台架构设计是什么样的？？？
如图所示：
-
渠道&应用
整个系统的对外部分；包括了各个应用的前端：App、小程序、公众号等等；
以及提供对部上下游企业调用的open API； -
应用平台
具体应用的母体；包括各个应用的服务端：小程序服务端、APP服务端等，即聚合基础服务能力，可以做流程编排和信息聚合；
网关:位于服务端和前端之间，实现前后端隔离，负责外部访问的安全验证和监控、以及内外部请求的路由和消息格式转换； -
后台
适配插件:用于连接内部系统和中台基础服务；插件是定制的，具体和每个企业的后台系统有关。
企业内部系统:企业的IT基础设施；
综上：
中台代表了企业核心的业务能力，它自成体系，能够为 C 端的互联网场景提供通用的能力，并通过各种插件和后台打通。
通过构建这样一系列的共享服务，我们就实现了各个渠道业务规则和业务数据的统一管理，
最终我们落地了一个强大的业务中台，可以很方便地扩展各个业务，实现企业整体业务能力的复用。
借助总的中台架构图，我们一起看下具体的业务场景是怎么样的呢？以外卖下单为例
特殊说明：
- 应用平台层：可以理解为通用聚合服务，聚合多服务之间的功能；
- 订单控制服务（Order Control Service，OCS），负责订单逻辑的编排以及前后台之间的状态同步，你可以把它看作是基础服务之上的聚合服务。
思考，应用端是否可以跨过应用平台层，直接调用业务中台服务呢？？？
-
不推荐，对于外部过来的请求，我们需要提供一些非业务性的功能，比如签名验证，协议和参数适配（外部的rest和内部的rpc）；
-
中台只是提供基础业务功能，前端过来的请求是代表一个业务场景，需要同时用到多个服务的功能，比如前台下单，需要用到用户服务，商品服务，库存服务，订单服务等，这不合适直接在前端做功能整合。
