做了很多年的软件系统和架构设计，由于本人很懒，没写过什么帖子或文章。但是自己也有些经验和想法，也总想拿出来给大家分享一下，探讨一下。最近，为了让自己能回炉一下知识，决定勤快一点，写些帖子，来总结一下自己对大规模系统架构设计的理解，清理一下思路；同时也给大家提供个正面或反面的东西做参考，和大家一起学习讨论。
有些东西，做过和没做过有时还真是不一样。大规模系统的玩法和一般规模系统的玩法是不一样的；做过大系统和没做过大系统的高级架构师，眼光还真有些不同。
工作中，发现许多人对这个还不是真正的理解。认为大系统和小系统的玩法都一样，或是以为自己区分了，却还是用小系统的玩法来设计大规模系统。随着业务的发展，系统需要不断的重构，不断的拆分、重整。由于当初架构设计不到位，后来即使费时费力，工程师们工作得很累，整个大系统还是零零乱乱。
从美国回来以后，经常会被问这样一个问题，中国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自动生成的程序类。正是由于这样一个简单的做法，节省了大量的人力资源；而且阅读性强了很多，不同部门工程师交流也方便了许多。
类似具体的系统设计和实现手段还有一些，在以后的帖子中再一一详细叙述。一口气写了这些，开场白就这样啦。后面准备不断的加内容；包括大规模系统常常遇到的问题，解决问题的思路等等。有兴趣的就给我发邮件告知一下，每次我加了新东西就邮件通知大家。我的邮件地址是[email protected].