最近有了几天的空闲时间，又开始了学习的征程。之前在极客时间上面订阅了《从0开始学架构》的专栏，在专栏结束之后，作者还陆续增加了一些文章上去，其中有一篇就是讲中台的。
原先我理解的中台就是一些基础的公共技术的聚合平台，作为各个业务的中介，通过技术的手段解耦业务模块之间的硬耦合，同时为业务提供通用的、基础的功能(例如：网络通信、数据存储、日志系统等)。业务就像是网络中的两个节点，中台就是节点间通讯使用到的网络。离开了网络，节点的功能就不易实现。业务需要在中台的肩膀上，才能更方便的构建具体的业务。就好比socket数据发送， 你可以使用TCP、UDP等传输层的协议，也可以直接发送基础数据，而不基于传输层。这样子，中台实际上只是一个资源团队，跟具体的业务是无关的，只专注于技术实现。就是人们常说的技术中台。
通过文章的学习了解，我发现，之前的理解仅仅局限于广义的中台概念。而业界一般所谓的中台，实际上比技术中台更上层，包含一些共性的业务在里面。最早提出中台战略的应该是阿里巴巴，推行“大中台、小前台”的战略。中台为业务提供业务能力，前台根据实际的应用场景实现用户业务。
本人之前在一家互联网公司的共享平台部门工作过，主要做的是移动端react-native的技术支撑。通过该平台业务可以便捷的与其他模块进行交互。基于平台的架构，以及其它独立的业务部门的能力，可以快捷的搭建起一个个不同应用场景的APP软件。平台部门提炼各业务线的共性的技术需求，最大限度地减少“重复造轮子”。通过业务驱动开发，在实现业务需求的过程中，可以实现很多创新。在这样的部门工作，可以接触到更多底层的技术、前沿的技术，这个对开发人员的发展是很有裨益的，而不总是为了繁忙的业务逻辑加班，很少有时间深入理解底层的技术原理，仅仅停留在业务应用层面。当然，由于不同的业务有不同的需要，为了最大化兼容所有的业务，一般需要随着业务的快速发展而不断的迭代。迭代的过程就是一个痛苦的过程，新旧特性会存在许多的不兼容性，所以发布往往要影响许多业务的使用。即使有些业务已经稳定了，但是伴随着新版本发布，业务也需要进行兼容修改发布，否则后期就无法继续使用。这也制约了平台的发展，许多新技术都不能快速的推进，受到业务的掣肘。这样实际是处在一个很尴尬的地位，既要影响业务，又要被业务影响。如果不是有强有力的领导来支撑，那就很难推进工作。
中台是属于业务层面的，提炼了共性的业务，可以在中台孵化新业务，时机成熟后再独立出去。平台呢，主要还是提供技术的支持，为业务提供基础的架构，本身不需要关注业务。
中台的好处就是在已有的基础上，可以缩短业务开发的周期，可以快速构建一个个新的业务，中台可以提供业务相关的完整的解决方案。缺点就是复杂，有难度，对工程师的要求更高。做中台需要懂技术还要懂业务。一般中台的出现，都是公司有面向用户的业务的。很多做底层支撑的公司，会存在平台的概念，和业务中台不是一个概念的。
在专业深度上，平台和中台就没什么区别了。作为支撑业务的部门，都提高了上层业务的开发效率，自身也可以在专业上更加深入，保障整个系统运行的稳定和高效。
在人力资源上，都节约了用人成本，减少了重复工作。
用户体验，中台和平台都可以花时间优化系统的性能，提升软件的流畅度、稳定性。
但是有一点，平台只提供了通用基础能力，不同业务间存在协同问题。中台，则可以在发展的过程中，逐步将他们整合协同起来，这就是中台的优势，中台可以提供完整的业务解决方案。
行动，才不会被动!
欢迎关注个人公众号 微信 -> 搜索 -> fishmwei，沟通交流。