漫谈大规模交易系统架构设计--前言
做了很多年的软件系统和架构设计,由于本人很懒,没写过什么帖子或文章。但是自己也有些经验和想法,也总想拿出来给大家分享一下,探讨一下。最近,为了让自己能回炉一下知识,决定勤快一点,写些帖子,来总结一下自己对大规模系统架构设计的理解,清理一下思路;同时也给大家提供个正面或反面的东西做参考,和大家一起学习讨论。
?
有些东西,做过和没做过有时还真是不一样。大规模系统的玩法和一般规模系统的玩法是不一样的;做过大系统和没做过大系统的高级架构师,眼光还真有些不同。
?
工作中,发现许多人对这个还不是真正的理解。认为大系统和小系统的玩法都一样,或是以为自己区分了,却还是用小系统的玩法来设计大规模系统。随着业务的发展,系统需要不断的重构,不断的拆分、重整。由于当初架构设计不到位,后来即使费时费力,工程师们工作得很累,整个大系统还是零零乱乱。
?
从美国回来以后,经常会被问这样一个问题,中国IT技术人员和美国的比怎么样,有什么差别?说一句实话:中国软件工程师的工作效率和强度比美国的高多了。再说另外一句实话,中国高级架构师对系统的把握和眼光离美国高水平还有一段距离。这就表现在美国工程师不用那么辛苦一样可以做出很好的产品;比如Google、Amzon、Ebay/Paypal等大公司的工程师们远没有国内工程师们辛苦,可是这些公司一样可以做出业界领先的东西。为什么会这样?有一个原因就是有些国内的系统设计前瞻性不够,导致很多重复工作,导致很多可以简单实现的东西需要用复杂的方法实现。
?
举个简单例子: 在Java应用系统中经常会用到DTO(Data Transfer Object),一般用一个类来实现。在小规模系统中,我们手工写这这些DTO类,很轻松很愉快。但是在大规模系统中,有成百上千的DTO,写起来就不是那么轻松;而且维护成本很大。如果公司人员流动比较大,维护成本就更大了。 解决这个问题其实不难。采用“文档即程序”的方法。文档是什么?XML文件,定义DTO所有的参数(Member)。程序是什么?DTO的类。文档怎么变成程序?CodeGen自动生成程序啦。简单吧,要做的就是维护那些DTO的XML文件;所有DTO的实际程序都由CodeGen生成。 Paypal使用了大量的VO(Value Object),用在各个方面的参数传递。这些VO其实就是一堆XML定义文件CodeGen自动生成的程序类。正是由于这样一个简单的做法,节省了大量的人力资源;而且阅读性强了很多,不同部门工程师交流也方便了许多。
?
类似具体的系统设计和实现手段还有一些,在以后的帖子中再一一详细叙述。一口气写了这些,开场白就这样啦。后面准备不断的加内容;包括大规模系统常常遇到的问题,解决问题的思路等等。有兴趣的就给我发邮件告知一下,每次我加了新东西就邮件通知大家。我的邮件地址是hubert.wu@alibaba-inc.com.