云栖会议.武汉峰会(二)

3 企业级互联网架构专场（下午场）

     下午分会场有不同主题，即有云计算大数据企业级应用实战，又有商业化和业务化角度来论述大数据应用的，而阿里云计算大数据平台架构是我颇为关心的，故以下只对系统架构进行论述。

3.1 企业级互联网架构实践

                                                                                                                                                                               ---------------------虚缇 阿里巴巴中间件架构师

        

              

    早期，阿里巴巴早期的架构设计是标准界面式War包形式：全部的界面和后台功能都集中于一个War包里面，故这个War包很大，一般多500M~600M左右，但是这样开发却存在较大的问题。比如，每个星期发两次包，礼拜二和礼拜四，总有一部分人会赶不上进度发布不了包，这样会拖累整个项目的正常发包；而且，阿里巴巴，淘宝，天猫之间又存在很多相似的地方，如果重新开发，就完全是Copy to Paste模式，导致人力、精力的严重浪费，基于以上存在的问题，阿里巴巴就把复杂的架构进行各种拆分：把共享的服务拆分开来，例如每个业务模块都会使用的用户中心，把用户中心从各种业务中拆分出来，大家在使用时只需调用接口就可以了，不需要重复开发。数据拆分包括：应用与应用的解耦，应用与数据库解构，应用与数据库的彻底解构，如上图所示。

       

     
        随后，阿里形成了共享业务事业部，可以分为共享业务和技术平台，技术平台是企业级互联网架构组成部分，其核心落地是使用中间件技术来实现。根据不同的业务可以快速形成淘宝，聚划算，天猫，淘宝，阿里巴巴等不同应用。

 

         在此过程中，阿里平台形成一批优秀产品，例如EDAS，DRDS，MQ等，EDAS可以一种调用服务的中间件，DRDS是分布式数据库，MQ是消息中间件。

 

         对于互联网上成熟组件和技术，如海量数据，docker，LAMP，开源，分布式等，网上有很多人鄙视阿里：“只是拿着开源东西用，没有任何贡献”。而阿里的观点是可以参考和使用成熟的技术，但是一定要先验证组件的成熟，然后弄懂其原理和设计，如果有业务需要，可以在此之上拓展。一个成熟的组件会让事情事半功倍，但是仅仅只是使用而不知其所以然，就会给自己挖坑而已。

 
阿里的架构设计中采用一系列原则：

• 尽可能拆分

      一个大型系统功能架构，应该尽可能拆分开来，让共享的，类似的功能分离出来，避免重复开发和代码冗余。并且，各个模块之间的关系应该是低耦合的。

• 去中心化

 

• 使用成熟组件

 

可以使用成熟组件，但是一定要先验证组件，然后摸清底层原理和设计原则。

• 尽可能的自动化

            

       从运维的角度看，只要人操作的事情总会出错，一定要把人参与的手动的事情，让其自动化和机器化。早期阿里运维人员有500多号人，但是随着自动化的过程，阿里现在运维人员不到100号人了。

• 数据化运营

 

从运维的角度看，对服务和应用实时性监控和管理。

• 异步化

 

让同步的事情，尽量异步化。

3.2 企业级分布式应用服务——“构”无边界

                        --------------------------------------------------------------------------------倪超（银时） 阿里巴巴中间件技术专家

 
      阿里早期技术现状：技术团队规模500人左右，开发使用War包应用，基于传统应用开发架构（Spring），业务量每年翻倍增长。但是存在很多问题，其主要三个问题：

 

• 问题I：业务支持缓慢，牵一发而动全身

 

• 问题II：数据库连接数：由于业务量迅猛发展，太多应用机器需要连接数据库

     在2009年之前，阿里是通过底层硬件撑起服务，虽然早期业务发展很迅猛，但是阿里盈利大多数去购买Oracle机器。早期Oracle是一年升级一次，但是后面发展成一个月升级一次，甚至购买了Oracle小型机都无法满足快速发展的业务需求，并且升级过程中会停止阿里后台服务，造成阿里的功能和服务的不可用，会损失大量用户订单，更重要的是这种方式不能从本质上解决问题。

 

• 问题III：数据孤岛

    天猫，淘宝，聚划算等APP应用，有很多相似的功能，如果各个APP单独存在，那么会造成数据孤岛。例如：用户注册这功能，每个APP都会用到这一功能，如果重复开发，完全代码重复，和数据重复，最重要的对用户友好性有造成负面影响。

 

    由于以上存在的问题，阿里从07年至今，基于EDAS进行服务化改造。

阿里的核心技术可以这么概括：

• I 自主创新走出技术困难，沉淀一大批成熟中间件技术；
• II 共享服务体系打破应用“烟囱式”建设方式，支持业务快速创新；
• III 云化基础架构高效支持业务增长，灵活的弹性伸缩带来巨大的成本节约     

去中心化服务框架，只是一个简单的开始。

 

 
立体化监控服务=资源+容器+应用

                   

      但是，随着阿里业务功能的拆分的越来越细，越来越具体，阿里功能模块却越来越多。开始总架构师能够把所有模块功能讲解清楚，如上图所示。但是后面根本就很难讲解明白每一个模块功能（没有回答是怎么处理）。从另外一个角度看，阿里的代码封装性却较好。

     

   

     并且，在定位问题的过程中，快速定位难度较大，例如：看到A模块错误日志，找A的模块主管，A主管看后台日志，发现是调用B模块的问题，让维护人员找B模块主管；B模块发现不是自己的错误，是C模块的问题；如此循环，一两个小时过去了，才找到问题根源。花费大量的时间和精力去定位问题，所以阿里使用EDAS研发出“EDAS鹰眼跟踪”，来定位问题。而EDAS链路分析作用是统计代码稳定性、方法负载均衡，如上图所示。

  

注：以上有些只代表个人观点和理解，如若与作者本人观点有出入，请予以包涵！