关闭

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

6153人阅读 评论(0) 收藏 举报
分类:

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链路分析作用是统计代码稳定性、方法负载均衡,如上图所示。

  

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

    
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:156028次
    • 积分:1967
    • 等级:
    • 排名:第19967名
    • 原创:39篇
    • 转载:84篇
    • 译文:0篇
    • 评论:8条
    最新评论