中台和微服务
微服务：微服务架构通常采用前后端分离方式，按照一定的规则拆分为多个可以独立运行、独立开发、独立部署、独立运维的微服务，从而满足业务快速变化及分布式多团队并行开发的需求。
中台：从使用者的角度来看，大部分的微服务架构都是在支撑一个前台，而中台解决的是企业级能力复用，而这种能力复用一定是多前台、跨部门的。
当然，微服务中也会提到复用问题，但这种复用一般指的是组件级别的复用，并未达到企业级的层面。一般而言，一个业务中台会同时抽调多个前台业务中可共享的能力，最终统一支持多个前台业务。
简单讲就是：中台不一定非得采用微服务架构，能够达到多前台能力复用的目标即可；而微服务架构也不一定要同时支持多前台应用，单应用的微服务化其实更多见。
（1）中台：
阿里的“大中台、小前台”架构：起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到共享事业部，避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务，均是基于这个“大中台，小前台”思路建设的。如下图所示：
“大中台、小前台”架构主要集中在业务共享服务层，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀，降低研发成本，提高研发效率。打破了产品壁垒，之前是系统之间要数据，现在是都去找共享服务中心要数据，共享服务中心提供统一的，标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西，可以快速孵化新的产品，试错成本低，产品敢于创新，敢于拥抱变化，原来追竞争对手都很困难，现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展，技术和业务能力能够沉淀积累。
“大中台、小前台”与微服务的关系
微服务体现去中心化、天然分布式，与阿里的中台战略思想类似，是战略的具体实现方式的一种。现有架构师可以学习这种模式来解决企业本身的应用高并发、高可用、运维等难题，也是现有互联网经典架构，毕竟是经过阿里实践过的，除了BAT，Uber、网易、美团、京东等互联网公司都在很早前就实现了平台微服务化。