架构漫谈
对于架构来说，每一个软件工程师都有自己的理解，我想从 架构的源头来谈一谈自己 的对于架构的认识以及理解。
架构的英文是Architecture，从字面的意思来看就是过程。社会上的架构，从人类的起源 来看时，当人们之间的工作发生分工之后，人们各自去干自己所擅长的事情，由此而来人类群体的力量越来越强大。既然分工发生了，原来由一个人干生存所必需的所有的事情，就变成了很多不同分工的角色合作完成这些事情，这些人必须要通过某些机制合在一起。这就是早期时间的架构模型。
以上面的例子为例 来讲把一个整体切分成不同的部分，分别有不同 的角色来完成 各自的任务，并通过建立 不同部分的相互沟通的机制，使得这些部分 能够有机的结合起来成为一个整体，并且完成整体所需要的活动，这就是架构。架构就是根据要解决的问题 ，对于目标系统进行界定，并且对目标系统按照某个资源进行切分，二切分的原则就是根据 每个人的擅长进行展工作。切分之后使得 这些部分之间能够进行有机的联系，组装成为一个整体，完成目标所有的工作 。合久必分分久必合，而架构实际上就是人们根据自己对于事物理解，将问题进行 分解合并，直到解决这个问题，之中将分解出来的部分分给各自适合部分，完成工作。
对于架构来说，识别问题也是最重要的一环 ，文章中举了一个例子，女主人让 男主人去 把袋子里的土豆切一半下锅，故事的结尾男主人吧所有土豆切了一半下锅，结果可想而知，这个问题最主要是 男主人解决问题没有从人出发，架构的基本也是从问题出发。解决别人的问题，而架构师应该搞清楚这个别人是谁，到底的需求是什么。 从问题的暴露点一点点去溯源寻找，一定会找出来是谁的问题，以及问题是什么。架构师如果要正确的认识问题就需要认识到这是谁的问题，有什么问题，才能更好地将问题分组，合理的解决问题。
当问题比较复杂时，人们承担的负载太重了，这个时候需要架构来讲问题进行切分。切分时实际就是将stakeholder 进行切分或者 合并，使得每个人的stakeholder 的权责都是相等的，都对自己的那一部分负责完成。而且架构的最终结果会体现在 组织架构上 ，只有这样才会 不断地让架构推进执行。树形结构一般是架构的最终结果，当树形结构的分层越来越多 的时候，架构的工作效率反而会低 ，在架构时要将树形结构尽量完成平衡树的结构，至整个系统的工作 效率达到最大。
软件的初期是同机器去模仿人的历史，在 计算机的软件开发过程中，都在有意无意的模仿人类的过程。在后来开发软件就是逐渐转到成本上来，成本为王，软件方面，为了简化难度，开始采用汇编，进一步出现了类似于人类的语言的高级语言，比如C/C++/Java等，这使得人类可以用类似于人的语言来和计算机沟通。软件工程师慢慢越来越多，开发软件的成本也越来越低。计算机就好像是一个只需要电，不需要休息的人，可以无休无止的工作。程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。以下讨论的前提，都是基于帮助别人写程序，多人合作的基础上的。结论对于单人为自己写程序也适用。
软件架构在现实生活中主要解决两个问题，业务问题以及计算机问题。这就是软件比较复杂的地方，涉及到软件本身的业务体系，和所虚拟的业务体系。根据以上的分析，所生成的架构，究竟那些算是软件架构呢，
软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。
说了半天的架构，那么架构师严格来说应该这么定义。架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个 leader。但是只是民意上的 leader 是没有用的，不能完全发挥架构师的能量