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、亚马逊，国内的阿里云、盛大云等等都支持此类的服务！
总结的看，整体上不过厮混说了一些服务分离的缘由、分离的原则、分离的优点及如何部署分离的服务！
0 条评论。