微服务架构如何实现网站服务垂直化拆分 _微服务架构

关于Aliware
【微服务架构如何实现网站服务垂直化拆分】Aliware是阿里巴巴中间件技术品牌，包含5个中间件产品，主要是：EDAS、DRDS、MQ、ARMS、CSB 。Aliware从2007年开始，经历了8年多的双11大促，每次大促都能使产品体系更上一个台阶。像JStorm、Dubbo、Rocketmq等等一系列的开源产品，无论在GitHub还是Apache这些顶级项目上，都是非常火的项目。
服务化缘起

文章插图
在2007年的时候，阿里技术研发团队大概是500人左右，主要业务是淘宝网站点，都是都在一个单一的WAR包进行部署，基于传统JAVA EE应用开发架构，使用的是Oracle数据库和JBoss服务器。当时整个淘宝网就是两个WAR包，一个是前台的，就是淘宝网；还有一个是后台的CRM系统，是给所有的客户支持人员使用的。

文章插图
在当时那个阶段，我们面临着非常多的问题：第一个问题，是系统的研发成本非常高。
首先，上百人维护一个核心工程，源代码冲突严重，协同成本极高。淘宝网当时是单独的一个WAR包，在运行的时候，就是一个工程，都是一份代码。无论是以前的SVN ，还是今天用了Git等一系列工具，代码冲突的问题是逃不掉的。
其次，项目发布周期太长。当年的淘宝网，是一个烟囱式的网站。它底层就是一个数据库，然后上层是所有业务逻辑的一个DAO层，专门负责访问数据库，再上层可能是业务层。所有模块的逻辑都在一个系统里面，都在一起部署。这样会因为某几个模块的开发效率低，影响整个站点的发布。
然后，错误难以隔离。这个是当时比较致命性的问题。比如说一个大的活动，我如果对时间的一个模块或者其中的一个if判断逻辑进行一些变更的话，整个活动页面会出问题，会导致整个站点都不可用。
第二个问题，是数据库能力达到上限。
淘宝早期是用oracle数据库，单机的oracle数据库连接数捉襟见肘，单机IOPS达到瓶颈，每天数据库CPU90%的负载运转，每年Down机最少一次。

文章插图
第三个问题，是数据孤岛。
当时淘宝、天猫、聚划算，万网等业务系统之间，数据是完全隔离的，数据不一致，无法复用，账号不统一，不能进行关联推荐，也无法进行大数据分析。
微服务架构的形成
在这三大问题出现之后，淘宝网开始做一些服务化探索。从2007年开始，进行了一些微服务架构改造。

文章插图
RPC框架：微服务架构的核心基础
在阿里内部做服务化的最底层、最核心的是两个框架，首先是Dubbo框架。Dubbo框架2010年诞生， 2011年对外开源。现在阿里发展到了第三代RPC框架，在内部代号叫HSF的框架，目前90%以上的应用，都在使用这样一个框架。每年双11大促也在用。

文章插图
消息队列：异步调用实现系统解耦
前面说到的RPC框架，重点是帮助我们解决，一个网站在进行服务化拆分的时候，各个模块之间的联系，需要通过RPC框架来进行一个同步化的调用，那么还有一些场景，它其实是不需要同步化调用的，是可以用异步去解决。
比如淘宝网平台上的手机充值业务，看似是一个串行的充值流程，其实可以通过异步结构来解决。首先，通过同步调用帮助用户确保他的下单在电商平台已经完成；其次，通过消息组件进行异步解耦，使得那些耗时长的不是核心链路的一些东西，能够不占据消费者在使用网站、App上面的主流程时间，优化用户体验。