请教大家一个关于中台搭建的问题

实际上是这样的，优势是借这个机会把代码全部重构解决性能问题。
中台通过统一项目的读写操作可以方便的管理缓存
中台可以通过网关权限配置来对系统接口（数据）权限快速进行全链路监控和熔断限流

模块数量一定是大幅度的上升，尤其是定制化的需求还在快速迭代中的，中台代码也会慢慢变屎。
你可能只需要查询某个表的一个字段，还需要等着对方写一个接口给你，效率实际很低。

最后业务做的不好，迭代太慢沟通效率问题裁掉一个团队，最后由一个团队写中台然后再在业务层调用自己写的接口脱裤子放屁也是屡见不鲜。

中台本来就是为了解决架构庞大的需求所以才分拆的，自然代码量也会很大。
想想中台是谁提出的，再结合适合中台模式业务的大公司，总共才几家？

我不是太清楚现在业界做法是怎样的，是从应用层沉淀通用和领域核心功能到下层？还是一上来就打造好下层的微服务？
但是按公司发展演进来说，一般都是直接从应用层出发，也就是先从上层出发，在功能日积月累的功能逐步迭代中，逐步把核心功能、复用的功能沉淀到下层作为服务的。
所以应用的需求是提到给上层的，但下层的服务层需要支撑上层的需求的实现。也就是说，今天需要对用户功能做一些新特性，那么除了上层这一波人需要开发，那么如果涉及到下层中台层的，那么这个需求也是要传递给到中台层。中台层作为内部服务，始终为应用层服务，所以有什么需求，从应用层的视角看待和提需求，而不是去看下层。


另外可以再了解一下领域驱动设计，里面限界上下文的概念就相当于服务的边界，需要了解如何划分这个边界。上层应用层永远都是调用下层的各种服务做应用业务流程的编排，下层服务实现了复用化和原子化，那么上层的应用业务发展可以根据下层提供的已有服务快速构建出一个新的应用来。

对于模块数量是否会大幅度翻倍，取决于你应用功能的复杂度，和拆不拆出中台没关系，哪怕你是单体大应用，不也是要拆模块，我们大多时候谈到的模块是业务维度的拆分，而不是技术维度的。所以你业务复杂度决定模块该拆多少。

什么是中台，有没有最佳实践。
结合公司当前的运营情况，分析下是不是过度设计，过度开发。

目前的场景是，需要对产品线的微服务进行整体重构，弄个中台出来，再拆出业务层，分两拨人维护。 （也是考虑到以后复用给其他产品线，有个打通整合的基础）
目前的场景是，需要对产品线的微服务进行整体重构 。可以，把服务梳理下，技术栈整理一下，架构清理下，很好。
弄个中台出来，再拆出业务层，分两拨人维护。 （也是考虑到以后复用给其他产品线，有个打通整合的基础）。这个事情，做不得。“分两拨人维护”，这是为将来买了一个大炸弹。如果两拨人，平级，那么谁听谁的？如果以某一拨人为主，那另外以拨人能听吗？
我推荐你以网关+服务的形式来做，以业务为维度做垂直切分。千万不要把一个业务分什么前台、后台。这是祸乱根源。

还有个点漏掉了，就是你做这一套，还有几个点需要明确，
1 、你们运维能力够不，做这一套，不管你是否容器化，必然涉及到大量的服务需要维护，这个部分的管理和治理是一个大问题。涉及到代码管理、流水线、服务发现、日志收集等等一系列的事情。需要你们的运维具有极强的能力。或者说运维具有一定的开发功底。或者你们有 devops 团队，或者就是全局 devops 化。
2 、你们的架构师或者 leader 能把握全局不？如果是一个狗屁不懂的领导，遇到需要决策的时候就知道和稀泥的话，还是别搞。

@dandankele 目前是成熟的产品功能，属于沉淀到下层。
本身模块是按业务功能做过拆分了，相当横向拆分，拆的比较独立，
现在是有些中台基础功能也需要提供页面操作接口，而且这部分考虑开放给项目修改，就得放到应用层，相当于得纵向再拆一份为二，这种拆法数量比较难受

所以毫无业务逻辑的中台层拆出来是干嘛的....

@9136347 我是感觉把一个业务再拆成两部分，这点类似把三层架构中的 DAO 层单独拆出去一样，有点奇怪

玩过换皮小游戏吗，中台适合这个

大部分公司的业务都是一锤子买卖，并不适合中台

非必要不中台

合理的服务化封装比为了构建一个中台架构更实用。 中台概念是用来卖产品和拿项目的。

@okey 这问题以前我也思考过，下层的一些服务后期可能会演进孵化成为一个具有独立功能、具备支撑力、可灵活接入的应用，不仅仅需要提供给维护中台的人操作页面，也可能需要中台为上层服务团队的人提供操作页面，例如这种形式：业务层应用需要接入使用中台层服务，那么直接通过中台提供的页面创建应用，然后得到 appid 、appsecret ，通过中台提供的相关接入方式做集成开发，就使得上层应用接入到了下层中台中，并使用中台提供的功能服务。

但是有个问题我也是长久以来的思考，就是，当中台发展到一定程度，例如我上述所说发展到类似一个完整独立的应用。此时，中台与上层业务层的关系会发生什么微秒的变化？目前架构中对我来说比较烦的两个问题，一个是拆分的粒度粗细把握，另一个是拆分后各种模块之间应该是怎样的关系。


我之前看领域驱动设计时，其中提到了限界上下文之间的协作关系（通俗的讲就是各个服务之间的协作关系），有如下几种：

- 合作关系（ Partnership ）：两个上下文紧密合作的关系，一荣俱荣，一损俱损。
- 共享内核（ Shared Kernel ）：两个上下文依赖部分共享的模型。
- 客户方-供应方开发（ Customer-Supplier Development ）：上下文之间有组织的上下游依赖。
- 遵奉者（ Conformist ）：下游上下文只能盲目依赖上游上下文。
- 防腐层（ Anticorruption Layer ）：一个上下文通过一些适配和转换与另一个上下文交互。
- 开放主机服务（ Open Host Service ）：定义一种协议来让其他上下文来对本上下文进行访问。
- 发布语言（ Published Language ）：通常与 OHS 一起使用，用于定义开放主机的协议。
- 大泥球（ Big Ball of Mud ）：混杂在一起的上下文关系，边界不清晰。
- 另谋他路（ SeparateWay ）：两个完全没有任何联系的上下文。

当拆分成各种服务时，势必可能对应到组织架构的拆分（康威定律），例如你所说会有两拨人分别维护。所以这两拨人之间如何合作，就意味着服务之间的处于怎样的关系，同时也是 5 楼 @9136347 中提到可能会有谁听谁的问题，这都与组织架构有关系。

所以服务之间的关系建议看一下领域驱动中的这几种限界上下文映射关系，并且哪种关系适用于哪种场景。


但是比较重要的一点是，无论怎么拆，我个人觉得最好能够画出架构的逻辑图出来，从架构图上我们可以看清哪部分属于整体架构的哪部分，讲拆分我们都是讲的逻辑的拆分，并不一定代表着物理上的拆分，主要就是让逻辑结构清晰，物理上要拆分的话，就是要考虑工作量、技术上的具体实施问题了。所以你说“这种拆法数量比较难受”可能指的是物理上要拆这么多是吧？

最后再回到你的问题上，中台需要提供操作和页面，那么分层肯定还是要的。假设中台一开始建立的时候，与上层业务的关系是合作关系，大家都遵循同样的需求一起开发，此时中台页面可能是放在当前架构下的业务层。但发展到后期，中台可能发展成为一个独立的应用，中台团队也具有比较大的独立性，那么中台与原来业务层的协作关系可能就发生了改变，深入到中台的架构视图中，中台自己拥有独立的纵向和横向划分体系，此时的中台的操作页面可能就纳入到这个体系的应用层中了，而不是在原来体系的应用层中。



----

以上纯属我个人的理解和看法，另外我暂时还没有从真正实施过这样大规模的工程，目前只是纯理论阶段，如果有架构大神在话的，希望能提供一些指导意见

如无必要，勿增实体

@dandankele 感谢分享，有了些启发，我再琢磨下

@okey 这个概念就是文科生扣脑袋想出来的。不具备实践意义。，