据说中台凉了？

军或者导弹往目标上送，作战能力max。

我们从系统上，也可以创造这样的一些中台。

业务中台，提供重用服务，例如用户中心、订单中心之类的开箱即用可重用能力。算法中台，提供算法能力，帮助提供更加个性化的服务，增强用户体验。数据中台，为公司内外提供行业决策基础服务，增强数据的应用能力。技术中台，提供自建系统部分的技术支撑能力，帮助解决基础设施，分布式数据库等底层技术问题。研发中台，提供自建系统部分的管理和技术实践支撑能力，帮助快速搭建项目、管理进度、测试、持续集成、持续交付。

总之，我们把这些能够保证前台需求绝大部分能力开箱即用，但又能快速响应前台需求迭代的服务，我们称为中台。

什么叫快速响应需求迭代呢?为什么要有中台呢?是否需要搭建中台呢?我们今天只从业务中台的理念上，来梳理一下一个中台的定位。接下来我们通过一个登录服务实例，从大家熟知的构建一个登录服务平台到构建登录服务中台，比较平台与中台的差异，看看怎么做到快速响应需求迭代。

根据我们的设计一个登录服务平台，大体需要提供发送验证码，注册，登录，登出，身份/权限验证 等服务。

开始总是分分钟都妙不可言，我们设计的平台总能非常好地满足业务的诉求，对于一些需要扩展平台能力的地方，也响应得比较及时。但是，慢慢的，事情好像出了一些变化。在平台的发展过程中，业务方越来越多，需求也越来越复杂。

A业务系统想指定特定的校验码平台，而这个校验码模式我们是没有对接过的。平台开发人员和业务只好扑腾扑腾派两个人去对接。B业务系统来了，说想在登录失败N次后，给用户发送短信提醒，发送邮件提醒，平台开发人员和业务只好扑腾扑腾派两个人去接这些需求。C业务也来了。D业务也来了。慢慢的，这个所谓的平台，已经没有任何人在做平台了。

本来我们设计拆分前台与后台，是为了让前台来满足用户需求的快速迭代，期望后台趋于稳定。当我们平台开发人员并不能确保我们能搞清楚

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!