架构师必需要知道的阿里的中台战略与微服务

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

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

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

 

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

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

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

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

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

为何要微服务化？

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

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

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

实践微服务架构的选择

微服务架构中所包含的内容：

 　　微服务是将企业通用服务按业务化分红一个个单体服务，加强可用性、服务易扩展、减小开发成本、减小服务发布对整个平台的影响。微服务是一种思想，实现有不少方式，企业转由单个系统转向微服务就要考虑不少问题，好比技术选型、业务拆分问题、高可用、服务通讯、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试，以及调度和部署等等，这并不是一些简单招数可以化解。

　　微服务框架必须可以达到借助虚拟化平台，可以按需建立机器并调整大小，借助基础设施的自动化从一台机器扩展到多台，拥有业务监控预警、异常熔断等等功能，现有框架有Dubbo和SpringCloud，Dubbo是RPC服务治理框架，和SpringCloud同样具有服务注册、发现、路由、负载均衡等能力。

 Dubbo和Spring Cloud有何不一样？

首先作一个简单的功能对比：

　　从上图能够看出Dubbo的功能只是Spring Cloud体系的一部分，Dubbo已停更了几年，虽然最近宣布增强了开源支持，但对于其它框架来讲已经很是滞后了。
　　须要说明的是 Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外因为依托了 Spirng、Spirng Boot 的优点之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

那如何作技术选型

相信更多的架构师为选择Spring Cloud生态，引用网友的理由：

1）从两个公司的背景来谈：Dubbo，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品。阿里巴巴是一个商业公司，虽然也开源了不少的顶级的项目，但从总体战略上来说，仍然是服务于自身的业务为主。Spring专一于企业级开源框架的研发，不管是在中国仍是在世界上使用都很是普遍，开发出通用、开源、稳健的开源框架就是他们的主业。

2）从社区活跃度这个角度来对比，Dubbo虽然也是一个很是优秀的服务治理框架，而且在服务治理、灰度发布、流量分发这方面作的比Spring Cloud还好，除过当当网在基础上增长了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程当中出现问题，提交到github的Issue也少有回复。

相反Spring Cloud自从发展到如今，仍然在不断的高速发展，从github上提交代码的频度和发布版本的时间间隔就能够看出，如今Spring Cloud即将发布2.0版本，到了后期会更加完善和稳定。

3) 从整个大的平台架构来说，dubbo框架只是专一于服务之间的治理，若是咱们须要使用配置中心、分布式跟踪这些内容都须要本身去集成，这样无形中使用dubbo的难度就会增长。Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来很是的便利和简单。

4）从技术发展的角度来说，Dubbo刚出来的那会技术理念仍是很是先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益很多。通过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo一直停滞不前，天然有些掉队，有时候我我的也会感到有点惋惜，若是Dubbo一直沿着当初的那个路线发展，而且延伸到周边，今天可能又是另外一番景象了。

　　Spring 推出Spring Boot/Cloud也是由于自身的不少缘由。Spring最初推崇的轻量级框架，随着不断的发展也愈来愈庞大，随着集成项目愈来愈多，配置文件也愈来愈混乱，慢慢的背离最初的理念。随着这么多年的发展，微服务、分布式链路跟踪等更多新的技术理念的出现，Spring急需一款框架来改善之前的开发模式，所以才会出现Spring Boot/Cloud项目，咱们如今访问Spring官网，会发现Spring Boot和Spring Cloud已经放到首页最重点突出的三个项目中的前两个，可见Spring对这两个框架的重视程度。

　　所以能够看到SpringCloud良好的生态是很是重要的，这里只讲到至SpringCloud实现微服务，具体SpringCloud微服务的详情后面再介绍不作多讲，还有与微服务紧密相关的容器技术也是至关重要的，还有微服务的DevOps自动化运维到智能化运维后面再做主题介绍。

 　　最后要说的是因为服务能力的集中管控，很大程度会促进咱们一体化运维的能力，但在“大中台、小前台”的模式下，每个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力，这也将改变企业的组织架构调整。

 　　以上是每一位架构师都须要不断学习的内容，相关衍生出来的内容更多，这里只做抛砖引玉，文中部分引用了圈内大咖的内容 ，在此感谢他们的付出。