转帖自http://www.hellodba.net/2010/08/alibaba-dba.html
2005年
2010年
大师去了支付宝，道夫在阿里云，大辉去丁香园创业，文学转行做了老板，旺旺也即将去支付宝，还剩下我和donny两个老家伙。
“相濡以沫，不如相忘于江湖”。
–EOF–
原帖见：http://blog.sina.com.cn/s/blog_3cdcd4a90100ijr7.html，是公司一个架构师写的，非常不错！
一、【前言】
刚刚经历完一个公司的项目，涉及很多架构设计、远程接口。在使用（我们自身）平台设计的接口过程中十分曲折、全体痛苦，而我负责的传真接口却让外部客户（电信方）与内部客户（应用方）感觉愉快清晰而受内外好评。
因此，我感觉颇有必要将我历来的设计经验分享出来，以帮助团队成长，未来的项目中少走弯路，作出成熟的、高质量的接口设计。
二、【正确的人，做正确的事】
任何优秀的架构师都明白的道理：
1、需求永远是第一位的，接口为需求服务。需求是接口的“衣食父母”。
2、应用方（工程师们）也是另一种意义上的”衣食父母”，如接口架构不良、实现较差，难用难扩展甚至没人愿意用，则最终会被“父母”抛弃。
3、有时候，我们看似比“衣食父母”更专业、更有经验，但并不见得比“父母”更有“生活智慧”，不要去试图教训“父母”，或让“父母”适应你。相反，尽一切可能适应或满足“衣食父母”的需求才是正确的设计之道。
4、好酒也怕巷子深；好设计需要好的媒介加以表达。写一份优良的接口设计文档，并在评审中清晰明白的阐述设计思路，是架构师的基本功。
5、好酒是与好窖、好水、好温度、好酿酒师密不可分的（再加上一段时间）。让团队成员尽可能广泛参与设计与评审，才能集思广益、查漏补缺，更能沟通顺畅、执行无误，切忌孤芳自赏、闭门造车、欲速不达。
6、如果你的团队中的“木桶效应”非常明显。你需要做两件重要的事：不要让自己的工作成为短板；尽可能补救那块最短的板。
三、【人与制度】
人与制度的关系，就像人与自然的关系。人能改变自然，但首先是被自然改变。
优秀的设计背后一定有优秀的作者，但如果“自然环境”不良，好设计也难以诞生或容易夭折。
如果你的团队一直不能诞生优良的设计，最大的可能只有两点：人或自然环境相当不佳。
具体到影响设计质量的制度建设上，我只建议4点：
1、让你团队的最优秀者作独立设计师或主设计师，无论是产品设计还是架构设计。
2、需求评审必须严格且广泛参与，业务流程图（注意：不是PageFlow）与业务规则描述是产出物中的必备内容，可多轮直至全部细节都经过评审
3、架构与接口设计的评审也必须同样不可省略，可多轮直至满足全部需求点（含潜在需求）方可通过评审
4、接口的设计与现实最好由同一人负责，别推脱或假手他人，甚至让新人或实习生来开发接口的实现
四、【接口的协议与框架】
目前，最常见的远程接口协议是基于HTTP协议基础上的soap、hessian、Json-RPC等。前两者，我应用已久，我对技术人员的协议建议是：hessian。
关于常见远程协议的比较，可参看JavaEye上的一篇文章：http://dalezhu.javaeye.com/blog/190962
对于Java开发者来说，支持soap（webservice）协议的最好的框架类库是xfire（另一个是axis远不如xfire好用）；而支持hessian协议的框架类库，最好的就是spring。因此，hessian+spring是我的推荐，也是很多架构师的不二选择。
五、【远程接口的架构设计】
比起协议与框架的选择来说，接口的架构设计才是体现设计师真正水准的分水岭。
一般来说，无论远程接口还是本地接口，常常会有异步执行的情况：即调用方call被调用方的接口，同步返回请求成功，但实际操作是被调用方延后去执行的。这种时候，提供回调接口是最佳选择，只有万不得已之时，才考虑让调用方轮询被调用方的接口，以查询执行结果。
因此，回调模式与轮询模式相比，无论是及时性、安全性、可靠性以及性能效率上远胜不止一筹。只有一种极特殊的情况下，我们完全无法采取回调模式：即被调用方的系统过于老旧，不可改造，无法回调不同的调用方。大多数时候，我们都可以用回调模式取代轮询模式，甚至可进一步做得更完美一点，让被调用方对于调用方不存在直接依赖（答案我不直接讲出来，自己思考一下怎么将<直接依赖>变成<优雅且万能的间接依赖>）
架构方案也是综合技术能力的体现，需要设计者在协议规范、语言能力、面向对象思想、数据结构、设计模式等方面不能存在明显短板。记住：一份出色的设计文档是你设计工作的最终载体。
六、【远程接口的设计实现】
我列举一些易犯（特别是接口设计的新手）的常见问题：
1.不定义接口类(interface)，而是直接定义抽象类。
2.接口返回对象参差不齐，随便定义。
——最好定义全局统一的Result对象：resultCode（全局返回码）, resultObject。
3.异常处理非常不统一，有时候用CheckedException，有些时候用UncheckedException，有些时候用ErrorCode。
——我的建议是所有异常在方法内部捕获，统一在ResultCode（全局返回码）中定义一段错误码，通过输出结果返回。
4.使用Map作接口方法的输入、输出，还美其名曰：简单灵活。有时候甚至只有一个Map作输入。
——Map非常不适合作公共API方法的输入输出（仅非常特殊时除外），直接导致弱类型问题、易引发潜在BUG且调试困难、不容易书写数据对象的（反射式）校验代码。另外，有些人反映hessian协议下存在Map中的自定义对象的序列化问题，其实很简单：1、不要使用Map；2、覆盖一下这些对象的hashCode方法。
好的接口方法的输入、输出无不定义为强类型，且应分别输入多个不同的业务数据对象（易于校验、维护与测试）。
5.接口包不提供输入对象的校验，对象长度、格式等只在文档中说明。
——建议接口包统一提供输入对象的校验：是否必填、长度与格式。最好定义一个Validatable接口：含validate方法，同时让所有输入对象实现之。
6.远程数据对象未实现序列化接口。
7.未考虑远程接口的安全性问题。
——有两种方案可让远程接口提升安全性：一、使用HTTPS协议；二、接口方法上增加一个安全码参数作安全检查（方法一：调用方与被调方用同一密钥对时间戳作DES加解密以便比对）。前者属于协议层安全，后者属于应用层安全，两者也可以同时提供，我建议仅用后者即可。
8.不作单元测试。
——关键类的public方法最好先作单元测试。另外，如完成一个接口方法的实现类，最好书写单元测试代码自测之（事半功倍之举）
还有很多细节问题，需要你自己的分析、判断与经验。这里请牢记一句话：细节决定成败！
当你完成一个接口类库包，就可以打上版本发布（建议与接口文档同时发布，且版本保持一致）。如以后升级类库，记住先升级文档。
七、【后记】
到此，我已经比较全面的介绍了接口设计主要原则与重点，但仅靠别人的分享与培训是不足以成为一位出色的设计师的。
一年有新的开始，新的开始就会有新的挑战。
现在阿里巴巴-B2B-技术部-国际网站技术部向广大互联网及IT同仁公开招聘。
我们有设计独特的办公大楼
我们有优雅的办公环境
我们有宽大的食堂
我们还有很多活动
如果你是单身，我们还有众多的美女和single Party
当然以上只是让大家知道阿里是一个非常现代化，简单，开放，快乐的公司。当然不是说你想来就可以来的，必须等满足以下的要求
开发工程师数量不限，要求：
1、语言不是重要的，技能还是需要的，思想也是重要的，无论是C++，Java，OOP的概念还是要熟悉和了然于心。
2、年龄也不是重要的，阿里有超过36岁的工程师，只要你坚持，我们可以让你一直在技术的路上走下去。
3、我们给予的薪水可能没有微软，IBM这么高，但是你能得到的不是一份螺丝钉的工作，而是创新，责任，创造性的技术工作。
经理一名，要求：
1、如果你希望你来到阿里后，觉得做上了管理的岗位，可以摆脱以前单调的编程工作，上升了一个台阶了，那你错了，在阿里，管理绝对是一个比编程更难的工作，有时候你会有一种有力使不出的感觉，在这方面需要有点管理的天赋。
2、先去了解一下阿里的技术，你的老板是我，我会严格地对你，但也会帮助你，能不能成功，就要看缘分。
3、你将负责一个未来有10-20人的团队，而且其中有些高级工程师的薪水可能比你高。
4、希望对互联网的应用有所掌握，要求技术出生，但不要求技术专业，因为没有技术，你将会缺少技术的感商，很难于工程师交流（关于感商的理解，请搜索我的博客“感商”一词）
共同的希望：
1、希望你们都是务实的理想主义者，在物质和精神层面上都有所追求，如果你脑子中只是金钱，对不起，阿里不适合你。
2、希望能做好准备，到阿里是一种磨难，是一种考验，我们不承诺你会升官发财，不承诺你会得到很多成就感，但会承诺你一定会很郁闷，会经历挫折，会得到很多磨练。
3、希望你们能够多注重技术以外技能的培养，只掌握技术，在你未来的提升空间中，帮助是非常有限的，你还要关注的有很多，例如沟通，组织能力，计划能力，影响力，决策力，责任心，方法论等等。
如果你对阿里的技术工作或技术管理工作感兴趣，另外你需要来杭州，克服地域的问题，以上都没有问题的话，可以联系我，我的邮箱在About Karl中有，附上你的简历，我们将很快与你联系。:)
转自我以前的老板-Zen在Aliway上的文章。
很高兴看到阿里云的成立。这意味着阿里已经把对互联网技术的投入提高到了的战略高度。过去经常听工程师抱怨阿里不是一家技术公司。现在再没有理由可以这样抱怨了。但是要实现这个战略，没有技术储备是不行的。招聘和培养工程师显然是目前集团各子公司同时面临的一个令人头痛的难题。
由于曾经在硅谷工作过，我常想，为什么硅谷有这么多40岁以上的工程师，而国内30岁以上的就已经寥寥无几了？为什么硅谷的工程师的技术寿命可以这么长？为什么他们可以不浮躁，不急功近利呢？阿里要走102年，阿里的工程师可以一起走多远呢？
在国内，有2-3年工作经历的工程师就可以算有经验的了。工作了5年以上的工程师往往会考虑向管理岗位转型，或者向业务转型。中国目前处于高度发展的阶段。很多企业缺乏管理人才，工作5年就被提吧为干部很正常。但留下的后遗症是30岁以上的优秀技术人才极度缺乏。
在硅谷，5年以下工作经验的人都算是初级的。一般高级工程师需要5年以上的工作经验，架构师一般需要10年以上的工作经验。这还不算上大部分硅谷的工程师都有计算机硕士学位。毕业的时候一般已经是24，25岁了。再工作10年，35岁才升为架构师是非常正常的。然而，公司里的架构师有限。其实大部分40岁的工程师仍然在一线工作，比如写程序，做测试，进行项目管理等。
美国硅谷是计算机人才集中的地方，也是创业公司群集的地方。在硅谷，从只有几个人到几十个人的创业公司比比皆是。他们的共同梦想就是经过几年的奋斗，通过技术的创新，再次缔造像英特尔, 苹果，思科，甲骨文，雅虎，Google，Facebook等这样的神话。即使创造不了神话，也可以通过IPO或者被收购的途径创造财富。在这样的环境中，公司对管理人才的需求同样是非常大的，但为什么仍然有大量的工程师“无动于衷”，仍然从事着技术活儿呢？
我认为有两个主要原因。
一个是外因。在美国，管理岗位的待遇和技术岗位待遇相差不大。特别在崇尚技术的硅谷，经理的地位并不比工程师高，甚至更低。比如架构师在公司里的重要性往往要超过经理。因此管理岗位的“诱惑”并不大。在这样一种技术氛围中，走技术路线很正常。
但是即使在这样一个技术环境中，硅谷对管理人才依然需要。当工程师表现出色时，也有很多机会转成管理岗位。然而相当一部分工程师会主动放弃这样的机会，而继续干他们的技术活儿。这就是内因在驱动了。技术工作和管理工作的本质区别是，前者面对的是系统（软件，硬件等），而后者面对的是人。系统问题再难，只要有足够的时间和资源，一般都可以解决。越难的问题，解决之后越有成就感。而人的问题，有时候看似很简单，却解决不了。是人，总要有头疼脑热，生病的时候。是人，免不了产生情绪，从而影响工作。有人的地方，就会有矛盾，就会有摩擦。简单地讲，系统会按照事先设定的逻辑运行，是死的，因此往往可控，可规划。而人是活的，不是输入几条命令就可以控制的，而是需要沟通，需要感情的。因此，大部分硅谷的工程师很“聪明”。他们主动选择“简单”地工作。白天好好地工作，晚上好好地生活。何必去“自寻烦恼”，转做管理呢。
其实不光是硅谷的，其它地区的工程师都有一个共同的性格特点，追求简单，追求完美，思维方式上比较理性和逻辑性，看问题比较趋向于非黑即白。这样的性格非常适合做技术工作，可是我们中国的工程师有时候偏偏看不到自己的这个特点。
不想当元帅的士兵不是好士兵。工程师希望向管理方向发展是非常正常的。但问题是为什么和怎样？我碰到过不只一个工程师告诉我，希望转做管理的原因是担心今后年级大了，技术能力跟不上了。我觉得非常可笑。这就好比是一个士兵说：我杀敌本领不行，不适合上战场，那就让我做军官吧。一个没做过士兵的元帅肯定不是好元帅。其实做技术和当兵毕竟不同，不是靠体力吃饭的。年级大点往往是优势。
我觉得走技术路线对工程师性格的人是一条捷径。如果能静下心来仔细钻研技术，一定能在某个方面做得比别人好。这里的关键是好奇心和耐心。在今天这样的信息时代，找到答案并不是一件难事。难就难在有没有好奇心和耐心去找。比如，Java程序员天天都用到String这个类型。但有没有想过为什么Java语言里有String和StringBuffer两种字符串类型，而不是一种？有没有去看过String和StringBuffer的源代码？再例如，天天做网站和HTTP打交道，有没有看过HTTP协议？有没有尝试过不用浏览器，wget等工具，而用最原始的telnet方式来访问网站？看看这HTTP的头里到底是什么东东？在我面试过的工程师中，做过这几件事的人不到5%。
一旦了解得比别人深，就容易看到问题本质，产生信心，激发乐趣。这时候你的解决方案就比别人漂亮，逐渐建立起了影响力，成为了“专家”。因此公司里的疑难杂症会主动找上门来。你就比别人得到了更多的解决问题的机会，从而更快地提升能力。一旦进入良性循环，你的进步就比别人快，但付出的却不一定比别人多。这时候你已经走上了捷径。
在技术人才极度缺乏的中国，在众人盲目追求管理岗位的那点虚荣的今天，如果你的性格是工程师类型的，走技术路线其实是非常适合的。如果你才毕业，那你是最幸福的。你可以给自己制定3个甚至4个五年计划。例如5年打基础，10年变专家，15年国内知名，20年世界闻名。如果你已经奔三或者三十出头，那你快成熟了，但离开花结果还早呢。不信你看看下面几位我们都熟悉的人。
拉里-沃尔（Larry Wall）33岁时出版了《Perl语言编程》一书。之前他是一个系统管理员。
互联网之父温特-瑟夫（Vint Cerf）在发明TCP/IP时，已经35岁。
万维网之父蒂姆·伯纳斯—李（Tim Berners-Lee）在37岁时才发明了万维网（WWW）。
丹尼斯-里奇（Dennis Ritchie）的《C程序设计语言》一书出版时，他37岁。
Java之父詹姆斯·戈士林（James Gosling）40岁时才因为发明Java而成名。
苹果公司创始人之一史蒂夫•沃兹尼艾克（Steven Wozniak）在今年年初以首席科学家的身份加入一家创业公司，研发基于高速闪存技术的存储。他如今已经59岁了。
