我的“技术架构”之旅

本人曾就职于58， 三星 ，阿里 欢迎大家评论，关注。

本想自己定义一下架构设计的要点，发现百度百科中总结的就很好“系统架构既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案，并能把各种目标需求进行不同维度的扩展。”提炼一下：

熟悉业务：技术本身是无“价值”的，要落地到具体的使用场景中为客户/用户解决问题。

掌控整体又要洞悉局部瓶颈：我们时常要对技术实现进行优化、时常要解决各种隐藏的bug，但是正如“过早优化是万恶之源”这句话的深刻含义一般，我们应该在明晰全局的基础上再去确定需要解决哪个局部问题。

不同维度的扩展：面对不断的变化，灵活性与可扩展性是我们进行架构设计所追求的目标。

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

第一阶段：外包生涯

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

参考：华为代码规范文档， Google 开源项目风格指南 ；书籍—《代码大全》

第二阶段：研发单机软件

这是自己第一次独立负责研发一款软件，开始接触客户了解业务，然后诉诸于代码实现。在这个过程中有一个印象极深的片段，接手的代码有一个长达千行的函数，代码命名随意也没有注释，看得我云里雾里。最后导致自己付出了大量的时间，包括利用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开发、数据库、云服务、高并发等等）