我的“技术架构”之旅

导言：很久没写过涉及技术的文章了，因为进行职业转型后对技术有种很纠结的心态。热爱——每每看到五颜六色的代码窗口就会心里发酸，想起曾经那是生活中的一份灿烂心情；不自信——这么久离开技术会不会已经落后生疏（虽然一直没有脱离技术的学习与参与，但是失去了一线写代码的实践）。今天恰好去参加AWS（亚马逊云服务）的一个区域讨论会，一位亚马逊的架构师在为大家讲解AWS云服务及一些案例的架构设计，很多熟悉的概念，还有这位架构师的谦逊和真实，一切是那么亲切。所以心血来潮，想回顾一下自己做架构的职业之旅。

• 熟悉业务：技术本身是无“价值”的，要落地到具体的使用场景中为客户/用户解决问题。
• 掌控整体又要洞悉局部瓶颈：我们时常要对技术实现进行优化、时常要解决各种bug，但是正如“过早优化是万恶之源”这句话的深刻含义一般，我们应该在明晰全局的基础上再去确定需要解决哪个局部问题。
• 不同维度的扩展：面对不断变化，灵活性与可扩展性是我们进行架构设计所追求的目标。

这是一些做架构的核心要点，其中还有很多其他的点。看看我的点滴领悟。

第一阶段：外包生涯

作为技术人员仿佛会本能的排斥去做IT外包的工作，仿佛这样就会成为IT界“蓝翔”的代言人。其实做外包人员并不意味着低端和无成长性，特别是对于在一些有着严格规范和标准的外包企业中，有对代码规范和文档注释的要求；由于只需要做业务中一块，这就要求把业务功能和接口设计的足够分离。正是这段经历让我形成了规范的代码习惯和有了功能接口化、模块化的思维。

参考：华为代码规范文档；书籍—《代码大全》

第二阶段：研发单机软件

这是自己第一次独立负责研发一款软件，开始接触客户了解业务，然后诉诸于代码实现。在这个过程中有一个印象极深的片段，接手的代码有一个长达千行的函数，代码命名随意也没有注释，看得我云里雾里。最后导致自己付出了大量的时间，包括利用debug工具一行行跟代码才了解清楚业务逻辑，心里默默地走了数百遍的草泥马。随后我便用第一阶段养成的好习惯开始进行众多功能的分割，把这个千行的庞然大物分离成一个个套用的小函数，另外在代码（命名和注释）上进行规范，不但利于自己后期的维护，我想也不至于难为下一个接手的研发人员。在这段经历中，我开始有了把一些工具函数抽出来写成工具类的意识（这期间还看了很多开源的代码，从其中抽出不少工具函数）。另外一个重点，就是对单一程序插件机制的利用，比如可以灵活的调节界面展现元素，利用程序的动态加载机制（动态库）来对程序进行局部升级和逻辑改变。

参考：snort和 tcpdump的源码充分实践了程序的插件机制；博客文章—《提高工作效率的工具“类”》

第三阶段：Client/Server端编程

C（B）/S架构意味着开始接触网络编程、web编程。这个阶段对自己影响最大的应该是分层的思想。网络协议栈分层的精妙设计和java SSH框架的使用都深深影响了自己，比如自己一个即时聊天系统的架构设计就充分使用了分层的思想，包括后期使用分层的思想搭建了一些业务无关的技术平台，便利了自身也充实了公司的技术货架。

参考：博客文章—《IM系统架构设计之浅见》，技术平台源码github—高性能TCP网络服务器程序，基于TCP协议的远程过程调用框架客户端实现

第四阶段：转向Linux系统、服务端编程

2011年时随着互联网/移动互联网的风暴愈加狂烈，90%以上的后端服务都是Linux承载，客户端技术又太碎片化，所以自己提前预判，将自己的技术栈从Windows全面转向Linux，从客户端转向服务端。如果说自己的架构生涯里转折点只能选一个，我会选这个阶段。Linux体系和windows就是两种不同的文化，其中《Unix编程艺术》这本书可以说是我的精神导师，我阅读了不下四遍。书中的很多思想都成为我今后做架构的依据和准则，比如“模块原则：使用简洁的接口拼合简单的部件；分离原则：策略同机制分离，接口同引擎分离......”,浓缩成一个词一句话“KISS——Keep It Simple，Stupid!”。当Martin Fowler 与 James Lewis 还未提出微服务的概念时，依据这些思想我已经做了很多微服务的设计和实践。

参考：博客文章—《三读《UNIX编程艺术》——UNIX哲学》  《服务端架构中的“网关服务器”》

第五阶段：搭建互联网平台级产品

这个阶段因为自己的角色已经不仅仅是个技术人员，而且已经深入到业务和产品设计以及运营中去。这时的思路是一定要以业务指导架构设计，我们不可能考虑全面所有事，架构可以随着业务发展慢慢演化。但此时的架构范畴已经不单单是某个程序的架构，而是技术选型、架构设计、性能优化、 安全、系统发布、运维监控、业务数据分析等对整个业务链的支撑。

参考：待总结（包含移动APP，智能硬件、web开发、数据库、云服务、高并发等等）