后端技术 by Tim Yang

最近在高可用架构群、EGO会员群等多个场合，大家都在讨论架构师的能力的问题，架构师应该具备哪些能力？在面试时如何合适的评估一个架构师的能力？

架构师的两种类型

第一种是可以将业务实现的人，他可能需要整合公司不同部门的资源、解决不同技术模块整合、解决不同版本之间的兼容性、解决各个模块的技术选型等，解决任务的分解及分配，解决进度上出现的问题。当上面所有这些问题都完成后，架构师顺利帮助公司完成了项目目标。

第二种是在第一种的基础上，利用技术的力量，改进了一个领域的效率或提升了生产力。比如一个在现有技术基础上提升20%效率的视频解码模块、或者类似美剧硅谷中的，研发出一套压缩比很大且保持高质量信息的压缩算法。目前的大部分互联网创新在某种程度也是利用技术变革的力量，比如电子商务及在线教育等行业。

如果从输出结果的角度来看，架构师有两种类型，具备技术杠杆能力的和不具备杠杆能力的架构师。并不否认第一种架构师在战略执行层面的作用，他们是各个软件开发团队的中坚力量。但从影响力的角度，其归根结底是在一个画好的表格里面填东西，他从事领域的最终的格局是由市场、运营或者产品主导。而一种是真正具备杠杆能力的工程师或者架构师，他可以利用技术的力量，在填写一个格子的同时，利用技术的力量，将格子的功效放大，影响十倍或者百倍以上的结果。比如在音乐播放软件中，推荐算法的应用彻底改变了用户播放音乐的习惯与体验。

很多人所说的架构师的设计能力，大多也可以归纳到第一种情况。很多所谓的架构设计，就是拿着多年一成不变的分层模式往业务上套，把业务按照功能规划成软件模块填写到架构图，并且把上下游的调用串起来。这种设计的大多时候是起给客户或者领导展示的作用。程序员代码的整体构思，大多可以通过白板上或者白纸以及程序员直接的沟通很敏捷的完成，大多不需要一个专职画图纸的架构师来指导。

第一种架构师是可以不写代码的，因为他大部分所做的事情是跟人打交道、分配任务以及解决开发过程中各种进度问题。因此很多技术负责人面试时候看重协调能力等非真正的技术能力。而那些服务甲方项目型的公司，更是特别看重人际关系、沟通能力、展示能力等跟客户打交道的能力。另外一些软件版本历史包袱重的企业，则看重架构师的打补丁能力。由于功能型及偏执型型的团队偏多，因此在很大程度上造成了架构师的能力标准的偏离，在一些讨论的场合，过份看重项目执行中的个别技巧型能力，比如项目管理、人际关系等能力常常还占据了主流的声音。

但这类架构师只能勉强称为“技术架构师”，因为大部分时候，他做的事情是填格子，而无法做到利用技术的力量，把一个格子放大到10个格子及更多。在另外一方面，这些不写代码进而慢慢丧失代码能力的“架构师”，也不太可能利用技术的力量去做发挥技术杠杆的事情。当然技术架构师也可以驱动工程师去完成一个技术型的大项目，大型的项目也需要合理的组织，但并不意味不写代码的人就比写代码的人做得更好。而那些对技术体系有深入了解及一线体验的架构师，比那些只跟人员管理打交道的人，更有机会利用技术的力量促进变革。

因此如果希望一个架构师有令人满意的技术驱动能力，他应该具备代码能力，对技术有直接的了解及体验，进而能够精通如何利用技术来改变未来生产力。

如何面试及评估架构师的能力

Tim 的面试方法是，候选人需要第一步通过电脑上完成一个小型的代码实现，在代码基本符合要求的情况下，才会获得所有面试官可以接受的一个能力起点。如果不做这一点，面试时候，面试官需要费尽心思去问对方项目上更多细节问题，才可能了解一个候选人真正的开发能力。而通过考试，则可以在验证候选人具备一定开发能力的基础上，愉快的聊一些其他轻松的话题。

在EGO会员讨论时候，一部分创业公司技术负责人担心一些资深的候选人不能接受这种方式，国内这种现象确实也不少见。但换个角度来想，创业公司大多还在起跑阶段，需要的肯定是从事大量一线开发的人。如果面试通不过机考编程，或者是不愿意做题，这种候选人也未必能完全适合创业公司需要。而那些不愿意做一线事情的架构师即使进来，他大部分时候在分派任务或者强化流程，可能让公司的技术层级及开发环节变多、管理成本变高进而导致整体研发效率下降。

面试时候大家也认可的一些验证架构师能力的方法，比如把当前技术开发中遇到的一些典型性技术场景让对方来提出实现方案，以便评估对方是否具备应对类似场景的能力。在入职之后，可以让新的架构师独立承担及完成一些任务，以便考察对方是否具备独立的架构实现能力。

一场黑客马拉松项目，大家会首先选择那些业界做得不够完善、或者有较大潜在价值的领域。比如最近举行的Go & Docker Hackathon，参赛人员会首选Docker领域的服务发现、服务调度等领域。

Docker是一种软件打包及运行的技术，其主要思想是将软件打包成一个image并可以到任意的机器运行，运行时候已经被打包的可执行文件被隔离在一个叫容器的沙箱里运行，并独立于系统其他服务，安全性及资源占用方面都得到了有效控制。Docker软件以及大部分Docker生态圈的软件是由Google的Go语言(也称为为Golang)编写。

但上面提到这些Docker领域的功能需求和实现都较复杂，完成一项功能费事费力，在短时间尤其是一天的Hackathon期间内，很难较好的完成。反而是找一些技术实现简单的领域，解决一个较小的需求，不但可以快速实现，并可以有机会将体验做得更好。让项目在一个很小但又经常使用的点上打动用户，得到用户的关注及认可。比如这次就有一支队伍完成了一个Dockerfile（生成Docker镜像的配置文件）的编辑器，并且进一步可以将用户在测试环境的的操作录制下来，自动构造Dockerfile。虽然技术实现很简单，但是对很多Docker用户会带来便利。

很多公司在选择创业项目的时候也会碰到如此的情况，如果选择了一个技术实现复杂的领域，考虑到功能的完整性，早期的开发周期就会变得不可控。创业公司通常希望每个月都有新的产品迭代，但复杂领域的开发，预期1-3个月的项目通常会拖到半年以上，这无疑是增加了公司运营的风险。

Docker目前在实际环境中主要还是用在管理云平台上的服务，但Docker的这种隔离运行的思想也可以应用在更多领域，比如参赛中应用在硬件控制、可插拔的开放平台等领域的设想。

黑客精神的一个重要点是程序员通过自己的编程打破已有的软件功能使用方式，给程序员自身及其他使用软件的用户带来自由及便利。参赛作品中比较能触动这一点的是挑战Siri的封闭性的一个项目，他设想通过一个个外接的容器能将智能做得更扩展，延伸到生活各方各面。有点类似微信的连接一切的概念，不过连接之后HUB不是微信，而是一个类似Siri这样的入口。

从这个角度，大部分我观察到的程序员思想还都比较禁锢，一方面是从小缺少创新（或者改变）的氛围及引导，在被设计的道路上循规蹈矩的长大，学习成绩好就是一个好孩子。工作后比较正常的做法也是每天接受分配的任务，完成得好就是一个靠谱的成员；打破常规的改变的成本过高，也被视为不那么正常的孩子。程序员即使换工作，也经常落在在薪酬、Title等因素的考量上，较少有动力去首先考虑那些通过技术来改变一个领域的事情上去。

目前好的app会将数据存储在云上，给我们生活带来很多便利，我们可以方便的多屏之间获取到数据，也不用担心app及数据在本地删除后丢失的问题。但很多基于云平台的优秀软件到了国内就会出现一些使用上的问题。

比如Day One是一款跨平台笔记工具，得过苹果设计奖，也得到不少人推荐，功能确实很简洁实用。白天在路上用Day One写了一些文字，回来后发现uploading一直卡住，不知道是否跟文章中某些词语相关。打开iPhone VPN后，终于上传成功，但在电脑上还是半天下载不回来。忙了一些其他事情之后，发现终于同步完成了。

Day One底层可以选择用iCloud，Dropbox等云平台存储。这些云服务在国内访问速度及稳定性方面会存在一些问题。Day One可能出于功能简洁的考虑，将同步设计成后台进行。当同步出现问题时，界面上通常看不到相关提示，系统自动在后台重试同步。界面上也找不到任何同步按钮及菜单，也没有状态信息显示何时会进行同步，因此在同步失败时候，用户只能一筹莫展了。

在国外，由于云平台在基础网络链路及带宽方面都具有优势，因此同步阶段不会出现这么多曲折的情况。上面的问题更多是国内特殊的网络环境造成，软件开发商也无辜的被躺着中枪了，这是app存在的一类问题。

但并不是说国内的app就可以处身事外了，国内也有自身奇特的网络问题，比如一些厂商的DNS不定期的被劫持指向一些奇怪的IP。但开发商即使了解到这个反馈，未必有有效的手段短时间解决，这也是app存在的一类问题。

做互联网分布式系统的通常也有这样一种情况，在主从同步等场景下，数据只能保证最终一致性；互联网业务通常不会使用transaction来保证数据提交一致性，因此可能会存在半状态的数据，用户如果碰到这种情况并且会存在困惑，但开发商通常会采用事后修复的办法，从CAP理论的角度不会首先考虑引入事务来彻底解决，这又是一类问题。

上述问题是否能有效的解决？是否值得花大的精力解决？从“用户第一”的角度，所有用户的问题确实需要第一时间第一优先级解决，特别在影响用户范围足够的情况下。但上述这些问题都是小众群体及场景出现，而且都是在使用标准化方式的情况下出现了异常。

从架构师的角度，我是极力赞成使用通用化技术而反对自建轮子，比如不赞成用自己维护的UDP代替TCP，不赞成使用非主流或自己开发的数据库、框架、工具包；不赞成通讯上使用自定义的协议来代替XMPP，或者为了防止DNS劫持而去搭建自己的DNS方案。可以预见，这些自建方案的决策在一定程度上打开了一个潘多拉盒子，社区通用技术体系经过5-10年或更长时间的演进，经过较多问题的修改与避免。比如上面的TCP/HTTP RESET/URL关键词错误属于一个问题的话，TCP/HTTP协议已经很好的解决了前100个你看不到的问题。自建的体系从0开始搭建系统，可能需要将大量时间放在重复业界已经完成的功能上。

从工程师体验来说不太倾向于对各种特殊小众的环境都做一个适配方案。如果有机会能做这样一个比较，在“工程师体验第一（类似facebook的Hacker文化)”与“用户第一”做一个优先选择的话，究竟谁的成效很更好一些？老板们通常会倾向后者，类似有阿里的“客户第一，员工第二”文化；一些声称工程师文化主导的公司可能会声称选择前者，而且某些持这种理念的人也认为工程师主导产品改进的环境会激励工程师的主动参与及改进精神，而导致成效更好。另外一方面文化层面的东西很难直接比较优劣。

感谢新买到的低因伯爵红茶，让我写完这些文字后接着睡觉不会失眠。