架构一词，原本来自建筑行业。是用来设计建筑物的一系列固有模式，是前人经验和智慧的结晶。但在软件行业里，架构变得抽象和混淆起来。它甚至在某些时候被企业滥用了，比如某些企业在招聘要求上写到，招前端（后端）架构师，要求精通HTML（JAVA）、JavaScript（MYSQL）等等。在我认为，这些企业的招聘要求，就算说不上是错误，但肯定是不全面的。产生这个问题的原因，一方面可能是企业基于TITLE的考虑，希望能把TITLE定的更高点以吸引优秀人才的注意，这个无可厚非。毕竟能力更强的人才能体现更大的价值，能帮助企业提升更大的利润或降低更多的成本。另一方面就可能是企业的招聘人员对架构师这个职位的理解还不到位。因为在这则招聘启事的要求上写着的其实是一个精通某项技术的工程师，而不是一个俯瞰蓝图的规划师。
那么什么是架构呢？以下是书本上的解释“软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。”但我认为，这个解释是不全面的，因为一个系统的运行，远远不是仅仅靠类或对象所能支撑的。这里对软件架构的定义，是一个狭义的架构定义，它把定义的标准降低到了代码逻辑层面，一栋楼房里房间的设计是很重要，但仅仅有房间是构不成楼房的，楼房还需要楼梯，通道，走廊，还有很多的相关配套，这样才能住人。软件是一样的道理，在完成一个软件项目的过程中，我们需要很多文档提供软件开发过程的支撑，需要根据需要运用合适的开发方法，需要选择符合要求的数据库、编程语言、运行平台，需要一个有效的测试策略保证软件的质量，需要一个迭代来进行功能的扩展与修改等等。而这些我把它称作组成系统的“组件”，这些“组件”中有的是产生的目标和结果，有的则是支撑过程的“中间件”。在这些“组件”和“中间件”中，有许多都是一门专业的学科，都可以很详细的细分下去，所以这些“组件”或“中间件”又由许多“子组件”和“子中间件”构成，而它们也有自己设计法则，形成子架构。
所以我认为，架构是以上定义的“组件”之间的连接关系。架构不分顶层或底层，也不分前端或后端，架构是一个整体，一种关系。架构师的职责就是理清这种关系，画出组件之间如何部署与连接的“蓝图”并指导实现。技术工程师需要完美的技能，架构规划师需要战略的思维。可能你不太清楚RSA实现的具体算法，但一定要知道RSA能为你实现什么目的，为什么你要用RSA而不用椭圆曲线（或相反），这是对架构师的要求。
以上是我对架构这个概念的一点拙见，如果你也是一个在“在路上”的人，我很荣幸能和大家在一条路上并肩前行，也会尽量挤出时间在这里写下这“一路上”的点点滴滴与大家分享，希望你们喜欢。
