前言：

中国前三企业还是BAT，阿里就是其中一个大型互联网企业，今天为大家介绍阿里的中台战略与微服务，本文阅读大约需要八分钟，请耐心~

传统企业平台都是烟囱式的系统架构，企业内部为了迎合业务发展不停的打造各种系统，导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力，财力还有时间。但打通烟囱式系统间交互的集成和协作成本高昂，各大企业不得不借助ESB产品，构建企业服务总线，打通各系统间的交互问题。

但这种借助ESB“中心化”的服务架构缺点也有不少，“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点，而这个中心点的能力是很难进行扩展的，导致这中心会成为一个瓶颈。

2015年阿里巴巴集团启动了中台战略，目标是要构建符合互联网大数据时代的，具有创新性、灵活性的“大中台、小前台”的机制，即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。整体内容如下：

阿里的“大中台、小前台”架构

起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到共享事业部，避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务，均是基于这个“大中台，小前台”思路建设的。如下图所示：

“大中台、小前台”架构主要集中在业务共享服务层，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀，降低研发成本，提高研发效率。打破了产品壁垒，之前是系统之间要数据，现在是都去找共享服务中心要数据，共享服务中心提供统一的，标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西，可以快速孵化新的产品，试错成本低，产品敢于创新，敢于拥抱变化，原来追竞争对手都很困难，现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展，技术和业务能力能够沉淀积累。

“大中台、小前台”与微服务的关系

微服务体现去中心化、天然分布式，与阿里的中台战略思想类似，是战略的具体实现方式的一种。现有架构师可以学习这种模式来解决企业本身的应用高并发、高可用、运维等难题，也是现有互联网经典架构，毕竟是经过阿里实践过的，除了BAT，Uber、网易、美团、京东等互联网公司都在很早前就实现了平台微服务化。

为什么要微服务化？

在传统单体或SOA架构下，应用如果频繁升级更新，开发团队非常痛苦。企业的业务应用经过多年IT建设，系统非常庞大，要改动其中任何一小部分，都需要重新部署整个应用，敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中，通常大量使用外包团队，这导致采用的技术栈之间差异较大，统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级，并快速响应。

在此时脱颖而出的微服务技术，面对上述困惑几乎浑身优点：独立开发、独立部署、独立发布，去中心化管理，支持高并发高可用，支持丰富技术栈，企业可以根据需要灵活技术选型。

（一）微服务学习路线图

阿里架构难道只掌握微服务架构就够了吗？当然不，以下这些架构体系都是需要的。

（二）团队协作

工欲善其事必先利其器，工具对Java程序员的重要性不言而喻现在有很多库、实用工具和程序任Java开发人员选择。下图列出的工具都是程序员必不可少的工具，也能让团队协作变得更加容易，迅捷。

（三）开源框架

程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这种怪状，真要追究起来，怪不得程序员这个群体本身 —— 它是两个原因造成的。

那么我们需要做的就是阅读源码，掌握这些技术，深挖到底层。

（四）架构师筑基

如果你写代码的基础是不牢靠的，打怪升级的过程也是最慢的。道理很简单 —— 前辈们踩过的坑，总结的经验教训，你都不得不亲自用最慢的法子一点点试着踩一遍。

很容易养成 stackoverflow driven 的写代码习惯 —— 遇到不知如何写的代码，从网上找现成的答案，找个高票的复制粘贴改吧改吧，凑活着完成功能再说。写代码的过程中遇到问题，开启调试模式，要么设置无数断点一步步跟踪，要么到处打印信息试图为满是窟窿的代码打上补丁，导致整个写代码的过程是一部调代码的血泪史。

你周围最强的那个工程师的开发水平的上限就是你的上限。

（五）高性能架构

性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。

十余年的经验，让我对高性能，高并发有了很多深入理解，路线如下：

（六）并发编程

这个不用多少，都是常见的，但是不能因为常见，而选择不去做深入研究，这是我整理的路线，供大家学习，参考。