2013 北京qcon总结二 — Chris:DecomposingApplications

Chris:DecomposingApplications,这场是安排在第三天下午的,那会人已经走的将近一半,对于那些走的人没听到这场,个人感觉还是挺可惜,但是每个人处在每个不同的阶段,对于知识的需求不一样,例如以前的自己决不会在意这场分享也就可以理解了!当然这个老外不远千里来到中国不仅仅是做技术分享的,随便也打了很多广告。

因为全程是英文讲的,自己只能以那点可怜的英文来听了,大体意思都还算挺的懂。

关于作者:
POJOs IN ACTION 作者
Lisp 作者(待定)
CloudFoundry 公司创始人

这次主题首先介绍了我们传统的软件架构模式,然后再一步一步分析传统模式的问题并一步步演化,整体上有点像支付宝鲁肃讲的那次关于支付宝的整体架构变迁历史,infoq听到现在为止,真的大的东西基本没冒出来,大多数的网站架构仔细观察下的话,本质上都是一样的,还是回归主题吧,看看Chris是怎么讲的。

传统的架构模式

浏览器 —–> web服务器 —–> 部署到应用服务器的WAR包,整个WAR包中包含了所有的UI,WEB,SERVICE(N个服务),DAO —–> 数据库
这种模式是一个很经典的架构模式,历史上存在必然有其优点:易于开发、测试、部署,但是它最终最近历史的角落中是有其较大的缺陷的,或者说是面对新的形式已经更不上时代的潮流了,简单的说难以面对变化。
这里扯开点说,变化这个东西在现在这个世界是无处不在,既得客观世界的变化,也有主观能动性的人不同的需求都会去寻求一些变化,这种变化有好有坏,围棋中的术语叫,棋从断处生。生活中我们应该好好的利用变化来获取自己需要的一些东西。昨晚的淘宝十年晚会中,老马也提到了变化,是啊,顺着变化的时代潮流,你就立于不败之地!
对应到做软件架构,大的方面上说,在高层次抽象和分解模块,关注组件之间的划分及组件之间的关系,从变化的角度看,架构要解决的就是决定那些不变化的东西,然后更好的去适应变化的东西,这个就是好的架构!

回头看看这种架构模式的缺点
1.任何一个小的改动,都需要重新部署整个WAR包,当然听说现在facebook还是这种一个WAR解决所有问题的模式,不知道真假如何!
2.需要打断一个长时间运行的后台JOB,由于所有东西是在一个包里面,打断是必然的
3.会增加失败的风险,因为你将所有的东西放在了一个篮子里面

对于开发人员来说
1.如此导大家都不愿意去更新这个包,因为害怕失败,同时很难的去做A/Btest
2.启动部署将耗费大家大量的时间
3.由于整个UI,开发都在一个环节,那么不利于多工种间的并行开发,协调

必然导致的结果是任何一个特性的上线都将耗费大量的时间。

那么必然要干的事情就是拆吧,一个扩张良好的程序,应该从三个方面观察
Y轴:进行功能分解,根据不同的业务场景进行分解,将原本一个Service — AService、BService、CService
X轴:进行水平扩展,根据功能分解后,能够通过相同服务的复制,进行性能的提升,简单说就是增加机器
Z轴:数据分区,相同类似的数据进行分区

X轴是通过复制扩展,X轴的每个服务根据依据Z轴的分区原则,进行分区处理!

分解的几个原则
1.根据动词进行分解服务,例如ShoppingService
2.根据名词进行分解,例如AccountService
3.单一职责
4.unix设计原则,专注于一件事,并做到极致

分解的原则
1.分解的太粗,会造成上面的大架构的问题
2.分解的太细:
较大的运行开销
可能存在的网络开销
系统过于复杂,让人难以理解

从这里看,架构就是们艺术,艺术的东西就很难用一种标尺去衡量!
好的案例:亚马逊、ebay、netflix的架构

缺点
带来了复杂性
1.多数据源及多数据源之间的事务管理
2.实现一个业务需要夸多服务

什么时候开始分解
开始的时候开始采用集中式的模式开发,因为一开始就搞服务分解会降低开发效率,在随着系统成长后做重构

优点
有缺点,但是必然有其优点。
1.可扩展的开发,可以独立的开发,部署和水平扩展各自的服务
2.可以独立的处理UI
3.提高了错误隔离,相当于把鸡蛋放到了不同的篮子里面
3.降低了特性的开发周期
如此分解服务可以开发出模块化,多语种,多框架的系统,不同的服务可以采用不同的技术进行开发,只要系统之间采用的是通用的

如果服务粒度太小
1.比较容易采用新语言对部分服务进行重写
2.选择一个好的开发者 > 一个掌握一个门语言的开发者 ===> 多语言系统的架构
现在看到很多公司的架构不再是单一语言的系统,异构系统的出现越来越多,同事这种异构的选择是在合适的场景下选择合适的语言

划分好服务后,那么就是如何取独立的部署服务,让服务进行好的隔离和管理,同时要求是高效的(下面更多的是打广告时间)
1.vm或者是物理机
2.Linux 容器/LXc
3.JVM
4.jar/war/osgi bundle

这些东西可以自己搞定,当然也可以通过现在已经相对成熟的paas来搞定,国外的CloudFoundry、亚马逊,国内的阿里云、盛大云等等都支持此类的服务!

总结的看,整体上不过厮混说了一些服务分离的缘由、分离的原则、分离的优点及如何部署分离的服务!

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注