从分布式向中台化演变

分布式向中台化演变"/>

从分布式向中台化演变

       之前经历过一家p2p金融的公司，15年12月份刚加入这家公司的时候，整个公司就一个系统，当务之急是顶住日益增长的用户访问量，为此进行了长达1年之久的服务改造，总结一个字 ： 拆。

       拆

       1、将数据库 、 文件系统 、应用服务 拆开 ， 一台服务器，变成3台服务器

       2、将前端 和 后端 拆出来  （前后端分离）

      3、将后端服务拆成多个 （集群）

      4、数据库 读写分离

     5、服务系统水平拆分 ， 借款端： 用户模块、 账户模块、 风控模块 、支付模块
                                             理财端 ： 用户模块 、 账户模块、各产品模块、支付模块

     6、系统之间通过dubbo同步调用／MQ消息异步交互 。 redis分布式集中缓存管理 

16年底公司成立了一个业务中台的部门，当时几乎每个部门的业务部分，中台都想参一脚，但又很难插足。刚拆完，系统还需要磨合润滑和填坑，加上业务的迭代，中台部渐渐的被弃之脑后。其实从上边拆分出的几个业务模块来看，重复的功能太多了，中台化的思想归根结底一个字 ： 合 。 将不同部门，相同的业务形态抽象出来，以满足特定的业务支持。17年合规化项目，为中台迎来了崭露头角的契机。

     支付平台建设

     为了每一笔用户（借款人、理财人）资金对接到银行端，中台进行了支付平台建设，借款端 和 理财端 的支付提现方式，全部对接到支付中台。大大节省了合规化各模块的改造时效。

举这么个例子，并不是想说公司一路走来的磕磕碰碰，弯弯绕绕，而是想表明几个观点：

      1、 每一家公司，在前路未知的情况下，一开始不一定会考虑系统的性能、高并发等情况，唯一的目的：快速上线，看情况。
      2、在发现用户增长量较高的情况下，能用钱快速解决的，一般都会用钱去快速填平：垂直扩展，钱 --- 硬件设备
      3、考虑到并发量上不去，1秒卡顿现象频发，老板眉头满满的情况下 ： 集群 + 缓存
      4、集群都解决不了系统“慢” ，老板愁的情况下 ， 水平拆分，微服务化，都是一种选择
      5、服务过多，就会产生重复造论，系统顺序性问题。 老板愁的就是时间和人力成本了。中台化建设就是老板希望干一份活，能解决重复干活损耗的人力资源和时间成本。

大神们有什么地方不对的，感谢帮忙指正。给予提点，谢谢！！