后端技术 by Tim Yang

大部分工程师包括架构师都是从微观架构起步的。微观架构指在一个局部的领域达到设计及实现的合理性，比如写一个排序的程序，达到时间空间复杂性的合理性，同时在代码的易读性、扩展性及可维护性方面也达到一个合理的标准。但一个系统中不仅只是存在微观问题，宏观架构指一个更高层级的，全局领域的策略及架构设计，通过架构来最终达到对产品或系统在效率、成本上的收益。当系统变大之后，宏观架构的问题更突出，也更能取得收益。比如在一个互联网Web应用中，从微观角度来看，cache命中率自然越高越好，从设计上尽量让访问落在内存上。但是从宏观角度，只要SLA能得到保证，比如让70%的最近数据（可能只占1%容量）能够通过cache访问，而30%长尾数据（可能需要占用99%容量）是通过存储返回，整体开销可能会下降一个数量级，而整体性能也基本有没有大的变化。

Coding出身的工程师刚脱离微观问题的时候，可能会觉得不习惯。微观的问题容易看到成效，比如将一个程序的QPS性能提升了30%，这是一个容易度量的成绩，而宏观架构看起来很“虚”，也不容易快速产生成效，比如将一个大型传统的系统改造成一个SOA的架构。辛苦花力气改造完成，也不容易看到及度量成效，而且一些隐性的收益需要更长时间才能体现。

尽管如此，微观架构及宏观架构如同战略及战术一样，是相辅相成的。而且双方都有其重要性，无法判断一个比另外一个重要。微观方面，一个平庸工程师组成的团队，即使一个优秀的架构师从天而降，短期内也无法改变团队的成绩。同样如果技术领导只关注宏观层面问题，忽视代码细节及基本功培养，团队的产品始终难尽人满意。由于宏观架构的设计者通常在组织中拥有更大的话语权，如果对微观的问题缺少一个基本的理解，对微观的出现的矛盾不能做出正确的判断，系统的开发效率及运行效率都会出现问题。宏观方面，一群优秀的工程师，如果能聚集到一个优秀设计架构的平台上，肯定如虎添翼。在一个团队中，宏观架构及微观架构的人员需要达到一个合理的比例。

以下是以前思考的一些断言，你判断是这些是宏观还是微观架构？

• The C10k problem refers to the problem of optimising server software to handle a large number of clients at the same time (hence the name C10k – concurrent ten thousand connections). The problem of web server optimisation has been studied because a number of factors must be considered to allow a web server to support many clients. This can involve a combination of operating system constraints and web server software limitations.
• The goal of SPDY is to reduce web page load time. This is achieved by prioritizing and multiplexing the transfer of web page subresources so that only one connection per client is required. Transmission headers are gzip-or DEFLATE-compressed by design. Moreover, servers may hint or even push content instead of awaiting individual requests for each resource of a web page. SPDY可以用作HTTP RPC一个高效替代
• 普通硬盘的访问延时是SSD的5-500倍
• 使用event方式事件模型的编程模型可以极大降低线程之间context switch的开销
• Code review is systematic examination of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase.
• 在大型系统中，模块之间组合的架构可以看出整体架构的优良及团队效率
• 移动app方向，未来一段时间仍然主要以产品模式及运营方向主导，技术驱动领域主要集中在快速迭代能力
• 虽然大数据是以后的一个发展趋势，但是数据挖掘的大部分场景还只是浅层次的应用，系统瓶颈不在挖掘能力，而是在应用能力上

一个团队内部经常有很多针对不同场景的设计方案，同时技术系统在历史上出现的各种问题故障可能也会在事后记录下来，但是这些记录及文档通常并没有一个好的归属，随着时间的推移就淹没在邮件的海洋中。如果知识库具备，这里简单探讨一下相关作用。

团队中新人未经历过系统所有阶段，不能有历史的阅历。即使是老的员工，如果团队规模变大，或者是精力的原因，也不可兼顾到系统中所有的信息，因此设计案例及故障案例对一个团队共享经验及共同能力的提高都具有极大的帮助。

看书是一种最佳的学习方式，但是在互联网工程领域，很多经验及成果并无公开的书籍及文档描述，因此很多有志于在此领域提升的新人经常会碰到困惑，如果当前不在一个成熟的互联网公司，根本没有机会来提升自己。另外一方面，即使能进入这些环境，新人也会碰到另外一些问题，公司内的牛人忙忙碌碌，已经完成的伟大作品也很少被详细介绍，新人只能在日常零星的工作中逐渐去了解全貌，很难得到一个快速成长的机会。

这对老人也是一个启示，大家热衷于解决的新场景的问题并非最大的价值所在，新领域问题无非是根据个人经验，走了一条不那么弯的路而已。但是总结已有的典型设计加以抽象总结，形成一些系统性的设计库，或者将所有的故障及走过的弯路分门别类，形成故障库，这对于提升一个较大团队的整体能力，具有更重要的意义。

说了知识库的需求，也许有人会顾虑知识库的技术领域差异性，技术人员对专业细分领域之外的问题不感兴趣现象比较普遍。前端的对后端的案例分析不感兴趣，数据库工程师对开发领域的问题不感兴趣。因此需要案例材料尽量跳出具体的语言细节本身。但是技术人员如果能够跳出自身的认知圈子，从更宏观的视野来讨论及分析这些问题，对于综合能力的提高具有更大的帮助，这也是走向架构师方向的一个基本要求。

对于设计案例，理想的知识库需要有系统的分类，而且大部分新设计的功能都可以在其中找到一个对应的历史案例，虽然很少有两个系统完全一样，但是真正设计思想的区别并不会大。

随着案例知识库的完善，案例的讨论的深入，一个团队的技术能力得到了整体提高及升华。