“数据中台”究竟是什么？为何阿里等公司对它趋势若骛？
有幸读过《企业IT架构转型知道：阿里巴巴中台战略思量与架构实战》，从书中也吸取了阿里数据中台建设的一些思想。（这本书很不错，建议大家阅读以下）
阿里最早的时候，是只有淘宝的，后来有的天猫，我们就那这两个举例，如果没有数据中台的话，淘宝是一个系统，天猫是一个系统。这就是"烟囱式"的架构, 也就是每个业务线虽然类似但都各自搞一套。
这样"烟囱式"的架构，会有什么弊端呢？
重复建设和维护带来的重复投资：这个好理解；如果除了淘宝、天猫之外，想再建一个类似的系统，里面包括会员、商品、商家、物流、支付等等功能，一定很浪费资源。
打通烟囱式系统间交互的集成和协作成本高昂：一个客户在淘宝买了一件商品，又在天猫买了一件商品，那么客户应在在淘宝或者天猫任何一个客户端上，看到这两个商品；现在如果是两个独立的系统，那么很多类似的功能，做起来会非常费时费力。
不利于业务的沉淀和继续发展：例如某个业务流程需要优化，那么就要在每个系统里面改一遍。
“大中台，小前台”说白了可以看成：淘宝和天猫都有很多类似的功能，那么把这些功能单独的抽出来，作为一个一个独立的系统，比如会员系统、商品系统、物流系统、支付系统等等。一个完整的系统，就是一个前段+各个流程所需系统组成。
那“大中台，小前台”的共享服务体系到底有什么优点呢？
服务可重用：例如淘宝和天猫都要有支付，那么就单独做一个支付服务；不必为不同的前端业务，开发相同或者类似的服务。
服务被滋养：书中提出了一个观点：服务最不需要“稳定”。服务需要被不停的滋养，促使服务不断的自我成长，这样服务才能最终成为IT资源，而服务所需的滋养正是来自新的业务不断的接入。
服务助创新：共享服务平台中的诸多服务是经过清晰的沉淀，可以通过重新编排、组合，快速的响应市场，达成创新，说白了就是一个字儿——快。
服务敢试错：共享服务平台由于具备快速编排、组合服务的能力，可以以较小的成本投入来构建出一个新的前端业务，即使失败了，公司损失也很小。
希望我的回答，能够帮助到你！
我会持续分享Java程序开发、架构设计、职业发展等方面的知识和见解，希望能得到你的关注【会点代码的大叔】。
到此，以上就是小编对于phpcms搜索剥离与使用的问题就介绍到这了，希望介绍关于phpcms搜索剥离与使用的1点解答对大家有用。
