漫谈大规模交易系统架构设计方法--Divide and Conquer

大规模系统常见问题：

 

    大规模系统和小规模系统是不一样的。一般小规模系统一个牛X的高级架构师就可以完全搞定设计，他可能对整个系统了如指掌，能驾驭系统的各个方面。但是大规模系统就不是这么一回事。再牛X的人都是有能力和时间都是极限的，系统太大，牵扯的面太广，一个人是很难，或者说是不可能完全面面俱到的。这就需要从思想上做好准备，要把系整个统划规划好，集合多个架构师来驾驭整个系统

 

常见大规模系统的几个问题包括： 

    1. 系统太庞大，各个部分互相牵扯，纠缠不清。

    2. 数据库太复杂。通常一个表担负着多重角色、职责和任务，导致阅读困难，管理更困难

    3. 程序太多、太复杂。各部分牵扯太多，程序模块依赖太。加新功能时提心吊胆，生怕影响老的、自己不知名的功能出问题。程序维护也非常痛苦。

    4. 由于程序相互依赖太严重，几乎每次程序发布都是件痛苦的事情。经常由于一个功能块的问题导致大部分新程序不能发布。

 

 

解决方法：

 

    做大型系统设计，最基本的方法就是Divide And Conquer。如果不知道用这个方法，或者不真正理解这个方法。你就不要说自己玩的好大规模系统。

   Divide And Conquer说白了就是对大系统进行切分，然后每个子系统分别搞定。精髓是什么？

 

DIVIDE：

   Divide的原则：按业务切分。这点说起来容易，做起来很难；特别是对技术人员。因为技术人员往往纠结于技术细节，总是想按技术体系来切分子系统。而且主要技术人员能把别人说得一愣一愣的，技术上好像非常正确。但是，实际上他很可能犯了原则性的错误。

   按技术来划分，在中小系统中是没问题的，但在大规模系统中，就不一定行的通。或者我这么说吧，中小规模系统要按技术来设计架构，大规模系统的High Level划分一定要按业务来划分。设计大规模系统架构首先要干什么？第一步是搞清楚业务架构，业务上是怎么走的；然后给定出每个业务系统的范畴和业务系统之间的边界。再根据业务系统对应出每个子系统，再针对每个子系统做架构设计。

    所以，当你要设计一个大规模系统时，第一步是理解业务系统，High Level划分子系统。先一定把技术实现抛开，定出子系统范畴和子系统之间的接口关系。第二步再考虑子系统内部架构如何实现。

 

   各个子系统要是自我完善，有封装性。其它系统能而且只能通过本系统提供的界面接口来访问本系统，不能走后门。包括： 

   （1）各个子系统之间只能通过远程访问来交互，不能通过Java包等来访问。

   （2）数据库（Database或Schema）的封装性。别的系统不能直接访问本系统的数据，必须通过本系统提供的接口来访问。

   （3）杜绝流程依赖。别的系统不能依赖本系统的程序流程，本系统也不能依赖别的系统的程序流程。

 

    掌握以上的原则后，你才能开始设计大规模系统。否则，你害死开发工程师了；系统得不断的重构、划分，重复工作会不断的发生。

    大规模系统会有多个开发团队进行开发。有可能开发团队分布在中国、美国、印度。系统切分范畴一定要明确，接口一定要简明。否则，各个团队很难协调工作。

 

CONQUER：

   子系统的解决有多种方法。SOA是常用的方法之一。大规模系统切分好了，每个子系统的规模就减小很多。再用SOA来设计就比较得心应手了。

   有人问，那为何整个系统不用SOA来设计？这就牵扯到系统规模问题。如果一个系统提供100个Services，每个Service有可能访问其它的Service。这个系统会有多复杂？系统绝对会失控。因为每个Service之间可能产生依赖，依赖关系可能就一团糟。但是，如果是10个Services呢，就简单多了。

   子系统设计的技巧很多，后面再慢慢详细的谈。

评论

1 楼 ciding 2012-03-04  

感觉，看懂了些，接着看完，明天去面试