共计 1602 个字符，预计需要花费 5 分钟才能阅读完成。
什么是架构，什么是架构师？这仿佛是聊架构话题时永恒的问题。
从心田讲我真的不想答复架构具体须要做什么，架构师应该具体负责什么。因为从理论状况看，在不同的零碎层级，不同的需要下架构师的职责也会不同；从不同的技术角度看，架构师又是个变色龙——一时是技术的大拿，一时是技术的规划者，一时是技术团队的指挥者。
那么，该如何答复“什么是架构，什么是架构师”这个问题呢？这或者须要先搞清楚另外一个问题——一名程序员是如何走上架构师之路的？我从许多敌人那里理解到了很多理论案例，程序员走上架构师之路，总结起来最多的起因是因为他早前代码写的好。
那么，代码写的好就是架构吗？显然不是。代码写的好只是表象，做所有事件都须要布局，尤其是一个简单的软件系统，这更须要布局，否则可能连一行代码都写不出。简单的软件系统肯定会须要做很多形象设计、对象布局、接口布局等筹备动作。也就是“上一辈程序员”口中所说的：具体设计。做架构次要的事件也仍旧如此，须要对整个零碎进行零碎的布局：模块、通信、边界、扩大、技术下沉等工作。这样的布局实现之后我的项目方能失常跑起来。
当然，架构也不仅仅是布局，还要做的另一件小事就是技术辨认。辨认出零碎中技术的难易区域，并合成简单技术，使之成为一个个技术的黑盒子，在此之上再进行新的技术布局，使整个零碎从技术角度来看是分档次的，从难到易，从大到小，但各层之间又是相互的黑盒。这也常说的让零碎模块间达到“鸡犬相闻老死不相往来“的状态。
零碎技术的辨认实现之后还要对另一种技术进行辨认，即人的技术。什么样的工程师适宜写哪一层的代码，那一层的技术对程序员技术的深刻水平要求到哪个点上。在做完这些事件整个架构外表上看是安稳进行了。
但实际上，架构的问题肯定会再次前来打搅：首先是测试工程师来询问“对于整体零碎架构而言这个利用该如何更好的被测试？”“咱们须要用什么样的技术来更好地保障软件的品质？”而后是运维工程师来询问“该零碎将跑在什么样的环境之上？”“咱们应该提供什么样的服务器？”“服务器上咱们会做哪些配置和装置哪些根底软件？”“咱们须要提供一个什么样的网络环境？”“有什么样非凡的网络配置？”“咱们须要做哪些安全策略？”……此时，架构师不时会像是一个掉入冰洞的猎人无比无助，头顶成群的苍蝇飞着，这些问题，有的懂点，有的不业余，还有的据说过没干过，有些仅限晓得原理。其实这些辣手的事件是考验架构师的一种能力：技术的宽度。
一个架构师须要足够的技术的宽度。从软件到硬件，从开发到测试，从运维到平安等都须要八面玲珑的理解。当然你可能不是这单方面畛域外面最深刻的人，然而你须要晓得它们是怎么做的（不仅仅是皮毛，要深刻原理），并且要晓得它们组合起来是个什么样的货色。技术面也足够宽了之后，是不是就会成为完满架构师呢？
答案是不会，因为还有新的问题要过去。这次的问题诸如“零碎在将来的运行过程中运维须要做什么？”“零碎在将来的性能迭代中如何更不便的扩大？”“零碎应该怎么批改？”“零碎应该被怎么样降级？”这时的你是不断很困惑？是不是感觉这个架构的世界好长啊，怎么像保姆一样什么都要管。但认真想想这是应该的，因为一个零碎首次开发并交付只是它生命周期中的一小部分而已。前面的保护、革新、降级才占了整个软件生命周期的绝大部分工夫。你是它的架构设计者，是它灵魂之所在，你当然应该设计好它的将来。这也是架构师做好的最初一件事件：零碎将来的设计。
认真想想，上文提到的这些案例全是架构的糗事，但糗事其实是架构师成长路上的必经之路。因为一个没有经验失败的架构师肯定不是个好的架构师。只有经验各种苦难，越过各种坑和各种苦楚之后能力成为一个优良的架构师。架构师也是一个很独特职业，不像古代教育里曾经很成熟的人文和物理教育体系，怠惰的人大都能通过零碎的浏览和教育能走向胜利。架构更像一种艺术、一门哲学，架构师们也好像通过多年积攒后突然间就像买通了任督二脉。