一个架构师谈什么是架构以及怎么成为一个架构师-CSDN博客

架构的定义

先来看看软件架构的普遍定义吧。

一个程序和计算系统软件体系结构是指系统的一个或多个结构。结构中包括软件的构建，构建的外部可见属性以及它们之间的相互关系。

体系结构并非可运行软件。确切的说，它是一种表达，使软件工程师能够：

分析设计在满足规定需求方面的有效性。
在设计变更相对容易的阶段，考虑体系结构可能的选择方案。
降低与软件构造相关联的风险。

软件架构的生命周期

软件开发有其生命周期，它应该是：

而软件架构也有着其生命周期，它又是怎么样的呢？

软件架构的重要性

为什么说一个软件架构是很重要的呢？直接编程直接开发，多EASY？请看下面几点：

软件架构能够满足系统的品质
架构设计使受益人达成一致的目标
架构设计能够支持计划编制过程
架构设计对系统开发的指导性
架构设计能够有效地管理复杂性
架构设计为复用奠定了基础
架构设计能够降低维护费用
架构设计能够支持冲突分析

什么是好的软件架构

这个问题，可能大家一直都在问，包括一些IT企业也在问，对于这个问题的回答，可能不仅仅是一个简单的语句或者是定义就可以回答的出的，我们来看下面的几个形象的例子：

这个是什么东东呢？乐高玩具，乐高玩具大家肯定都玩过吧？

它即可以以一个完整的模型卖给你，你也可以把它全部打碎了重新从一个模型自由的再去组装成另一个模型，因为每一个乐高的模块在横向、坚向里都有标准的接口，这就是我们常说的高内聚、低耦合。

什么又是糟糕的架构

大家看看上面这幅图是什么？

一个是清代的八股文，一个是孔乙己。

还记得回字的四种写法吗？

那么你专门就研究回字的四种写法，但你有没有想过我把回字折开来又可以变成几个字？是否好折？

要知道最时髦的并不一定是最好的

为什么M1A2和阿帕奇直升机里不用A8处理器，或者是最新的奔腾处理器啊？实用、经过检验的才是最好的！

成功的软件又是怎么样的呢

我们谈的是软件架构，架构的最终体现是一个软件，那么什么是成功的架构什么是成功的软件呢？

大家看左边的这个图，是美国的“阿利伯克级”宙斯盾驱逐舰，右边的是印度模仿美国的宙斯盾自己设计和建造的”德里级”的“咖喱盾”驱逐舰。

两艘战舰一对比，怎么样？

一个是模块化的设计，整体线条流畅，战损时模块可以任意替换。
一个却是拼拼凑凑，线路外露，甲板上布满了各种电子设备和天线，一旦战损，极难维护

架构之美

架构，架构，到底什么是架构？我以前上大学时有一个70多岁的老教授，他上课每讲20分钟左右，需要2个同学”架“着去上一次WC，我们的架构师当然不是指这种”架构湿“。那么我们一直说的架构，到底它是一个什么样的东西呢？怎么样又可以做出一个完美的架构呢？

架构就像是迷踪拳

动作轻灵敏捷,灵活多变

它其实违背一切传统拳法，因此可以克敌制胜。

架构就像是独孤九剑

破剑式、破枪式、无招胜有招，它发源于传统武术，又扩展了传统的武术

架构就像是一件艺术珍品

有时一个看似简单的架构往往却是一件艺术珍品。

一个好的架构不应该受限于框架，受限于语言，受限于技术，受限于各种条条框框，它是一种意境。

架构时需要考虑的几个基本因素

JAVA通用领域的相关技术

当然，我们这边主要说的是JAVA，那么作为一名学习JAVA、J2EE的架构师来说，要具备一些什么样的技能才能达到架构师的水平呢？

上面这张图，我们这样来看，它分为3个部分：

顶部，是我们需要掌握的一些技术领域的知识，它可以使我们应对通用领域如电商、企业OA、银行保险金融等领域的一些解决方案和设计
中部，为了达到顶部这些技术我们需要了解的一些中间件、数据库、开发框架这些知识，它是一根支柱
底部，底部呢？它是我们的基础，为铺设我们通向中间或者更上层的一个基石，这也是为什么大家有时发觉我的博客和其它博客有不一样的地方，不仅仅有编程还有”中间“的这一层即数据库、性能、安全、框架搭建这些东西混合在里面的原因，因为我不希望大家通过阅读完了我的博客还只是停留在一个码农、码工、螺丝钉的这种水平上。

架构师的职能

说了这么多架构，我们来说说架构师吧。

大家看到了没有，架构师的第一职责就是关注：non-functional requirements，即非功能性需求。

很多人对功能性需求和非功能性需求的界线划分还是不清楚，我这边举2个例子说明一下吧:

功能性需求

页面查询，这个查询是关联哪些哪些数据库表，因为我的业务是有这样这样的需求，在界面A里点了一个按钮，然后弹出窗口B，在窗口B里要显示什么样的数据，最后界面A里点完后，当我打开界面B时哪块数据已经随之发生了更改。

非功能性需求

我们的系统查询速度小于2S，是否考虑使用异步查询、使用队队列机制，系统要求可以容纳1000个并发，这个系统要可以做成插件式的，要可以横向扩展，要符合XXX协议，这个Webservice要做成SOAP HEAD内带有BASIC认证，还是做成符合NTLM的认证的，还是使用令牌环认证的？这个下拉框要做成即可输入又可以下拉的，这块认证要访问LDAP？

很多以业务为主的项目型公司认为架构师就是trouble shooting（即排错、查错的意思，就是有错误、出问题了再找架构师），把架构师当成了fireman（救火员），可是你不自己想想为什么出了问题架构师过来2秒、2分钟或者1天半可以解决你们1个月几十人天天到零晨也解决不了的问题呢？嗯？

解决了说这是人家应该的，解决不了，说人家架构师不合格呢？是不是我们应该从这个软件最早的框架上、架构上去发现一下问题呢？

架构师啊，这不是一个trouble shooting的问题啊。

在节前我也进行了一些面试，出于纯技术角度来说，即走架构师，TECH LEADER这样的路线的侯选人。

我还是发觉了不少的问题这也是中国的一个通病：即我们的程序员，很多时候不是在做程序，而更多时候是在做业务逻辑，成了一个某一领域的业务人员了。

当然，我们的程序员在其职业生涯的前3年、4年都是做某一块领域的代码的，这个是没有问题的，但是请一定一定记住，我们是编码，是IT，是程序员，不是“业务人员”！！！

什么是IT？什么是程序员？什么是Tech Leader？什么是架构师？

这个问题大家有必要好好的去问一下自己，去好好的想一下，架构师的要求是什么？

我这边随便说一些东西：相信对一些要走技术道路的同学们是有帮助的:

TCP/IP协议，加密解密，计算机原理（增补反码），JPG码，MPEG2-3协议，逻辑电子电路，计算机编译器原理（堆、栈、队列），这些东西你平时工作时一直用到吗？这些是你一直关注的底层吗？

如果你是要走技术路线，一定一定请记得“数据库+ASP/JSP”不是技术，它只比表单制作，报表制作人员稍微强了那么一点点。

请一定记住，技术路线关注的是非功能性需求，非功能性需求啊，就是一种一通百通的东西，有了这块底蕴，任何需求和你说清了，对你来说是没有任何“难度”的，或者你再去学，是可以举一反三的啊。

最近一直面试一些侯选人，做架构师的，在此过程中我对此深有感受，找一个程序员开发不难，招一个架构师，难。。。唉，我觉得大家有必要要考虑一下，如果我走技术路线，我缺什么，我怎么补，还要关注些什么？

科技是第一生产力，管理方法论中的所谓的六SIGMA即六西格玛的第一条就是“技术人材是当下企业的第一生产力”，大家看看能够发财的是哪些公司？阿里，淘宝，支付宝，GOOGLE, 腾迅，互联网，高科技等等等一些企业，他们靠的不是业务逻辑，而是真正的技术，这足以说明问题了，所以大家如果要走技术道路，请多关注一下更细节，更底层的东西吧。

这也是为什么我在之前的博文中所擅述的那些东西的原因，可见企业IT项目开发之七宗罪。