成功的软件架构设计是高质量的，并且所花费的时间、技术决策等方面都能满足具体开
发方法的要求，具体应该有如下品质：
良好的模块化：每个模块职责明确，模块之间松耦合，模块内布高内聚，并且合理的实现了信息隐蔽。
适应功能需求变化，适应技术变化：典型情况是，应该保持具体应用的相关模块和领域通用模块的分离，技术平台相关模块与具体技术的应用模块相分离，从而达到“隔离变化”的效果。
对系统动态运行有良好的规划：应该标识出哪些是主动模块，哪些是被动模块，明确模块之间的调用和加锁机制，并说明关键的进程、线程、队列、消息等机制。
对数据的良好规划：不仅仅包括数据的持久化存储，还包括数据传输、数据复制与数据同步等策略。
明确、灵活的部署规划：这里往往牵涉到可移植性、可伸缩性、持续可用性以及互操作性等大型企业级软件特别关注的质量属性架构策略。
好的架构并不是“好的就是成功的”，而是“适合的才是成功的”。不适当的用时间换完
美，最后会毁掉整个项目。回过头来看看我们为什么花了大量的时间讨论软件开发过程及其
影响？除了明确我们初期需要在绝大部分技术细节都不清楚的情况下定义软件架构，还要考
虑初期我们就需要搭建一个团队协作开发的基础，让不同的小组针对不同的子系统和模块深
入下去，这种团队的秉性工作也意味着可能缩短项目工程的周期。
 
架构师并没有绝对的技术选择自由，还需要考虑经济性、技术复杂性、发展趋势以及团
队水平等诸方面的因素。最终，架构师的工作成果就是为整个开发团队的工作提供足够的指
导和限制，使他们沿着正确的方向进行下去。
 
下面，我们来探究一下成功架构设计的关键要素是什么，这些讨论将主导着本课程内容
的演绎，是整个课程最核心的知识.

一、软件架构设计
软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。
软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件系统的组织结构和拓扑结构。
软件架构是可传递可复用的模型，架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配，即满足，需求的职责分配到组件上。
软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质；能够使得不同的利益相关人（stakeholders）达成一致的目标；能够支持项目计划和项目管理等活动；能够有效地管理复杂性；等等。然而系统架构的给出必须建立在需求明确的基础上。
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。
二、架构的模型 4+1视图


逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。（用户关注）
开发视图：也称为模块(实现)视图，主要侧重于软件模块的组织和管理。（程序员）
进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。（并发，集成人员）
物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。（软件到硬件，系统工程人员）
场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。（用例图）
逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。
三、软件架构风格
软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式；惯用模式则反映众多系统共有的结构和语义特性。强调对软件设计的重用。
架构风格定义一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为“客户/服务器”模式，则不必给出设计细节，我们立刻会明白系统是如何组织和工作的。
1. 数据流风格




批处理序列
强调数据作为一个整体（数据必须是完整的，以整体的方式传递）


管道和过滤器
每个构件都有一组输入和输出,构件读输入的数据流，经过内部处理，然后产生输出数据流. (构件–>过滤器;连接件–>管道) （数据流的形式）


2. 调用/返回风格



主程序/子程序
计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用。


面向对象风格
面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。


层次结构风格
分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度。允许每层用不同的方法实现，为软件重用提供了强大的支持。（二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用）


3. 独立构件风格




进程通讯
进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作。


事件系统子风格（隐式调用 ）
事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐式调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。


4. 虚拟机风格




解释器
具有运行时系统行为 (自)定义与改变能力 。如专家系统。


基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。（一般用在人工智能领域和DSS中）


5. 仓库风格



在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。


数据库系统
构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态,另一个是多个独立处理元素,处理元素对数据元素进行操作。中央数据库管理系统通过自身机制如数据排它锁，共享锁等，实现数据高速访问，数据一致性，数据完整性。同时各独立数据处理单元之间互相不受约束。 (如编译器，传统编译器采用批处理架构，现代编译器采用数据共享架构风格。分析树是共享数据。)


超文本系统
主要应用于静态网页。


黑板风格
由一个作为全局共享数据的黑板，一个控制单元和多个知识源组成，主要应用与专家问题解决系统。通过专家知识和反馈逐步得到正确结果. (如语音识别)


6. 闭环控制架构


过程控制
工业中的过程控制是指以温度、压力、流量、液位和成分等工艺参数作为被控变量的自动控制。过程控制也称实时控制，是计算机及时的采集检测数据，按最佳值迅速地对控制对象进行自动控制和自动调节，如数控机床和生产流水线的控制等。（比如空调制冷，温度大于设定温度制冷，小于等于时停止，一旦大于继续运作）


C2


通过连接件绑定在一起按照一组规则运作的并行构件。

构建和连接件都有一个顶部和一个底部
构建的顶部都要连接连接件的底部，构建的底部都要连接连接件的顶部，构建		之间不允许直连。
一个连接进行直接连接时，必须有其中一个的底部到另一个的顶部。



四、分层C/S架构风格演化
1. 二层 C/S



二层 C/S 结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或Internet；(使用范围)
软、硬件的组合及集成能力有限；(扩展性)
服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏；(性能)
数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。(安全)

2. 三层C/S架构


表现层（Web层）

负责接收客户端请求，向客户端响应结果，通常客户端使用http协议请求 web，web层需要接收 http请求，完成http响应。

表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。

表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。

表现层的设计一般都使用 MVC 模型。 MVC 是表现层的设计模型，和其他层没有关系。
业务层 （Service层）

它负责业务逻辑处理，和我们开发项目的需求息息相关。web层依赖业务层，但是业务层不依赖Web层。

业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。 (事务应该放到业务层来控制）
持久层 （dao 层）

负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进行持久化的载体，数据访问层是业务层和持久层交互的接口；业务层需要通过数据访问层将数据持久化到数据库中。

持久层就是和数据库交互，对数据库表进行增删改査的。

优点:
（1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。(逻辑独立清晰, 可维护性/可扩展性)
（2）允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。(可升级性/开放性)
（3）三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。(开发维护成本/速度/技术门槛)
（4）允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。(安全)
3. 三层B/S架构


用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。(客户端)
基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。(服务端)
B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。(开放性)
缺点:

B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
B/S架构的系统扩展能力差，安全性难以控制。
采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。(性能)
B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用.

五、MVC的架构风格

MVC 全名是 Model ViewController，是模型(model)－视图(view)－控制器(controller)的缩写，它是分层架构风格的一种。主要解决 将与 UI 相关的逻辑都定义在针对视图的相关元素的事件上 的问题。
MVC 中各个部分的分工与协作：

Model 是对应用状态和业务功能的封装，我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理，在状态改变的时候向 View 发出相应的通知。
View 实现可视化界面的呈现并捕捉最终用户的交互操作（例如鼠标和键盘的操作）。
View 捕获到用户交互操作后会直接转发给 Controller，后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用，Controller 会直接调用 Model。在完成 UI 处理后，Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。

六、MVP 的架构风格

MVP 是从经典的模式 MVC 演变而来，它们的基本思想有相通的地方：Controller/Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。
当然 MVP 与 MVC 也有一些显著的区别，MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”，这在 MVP 模式中是不允许的。在 MVP 中 View 并不直接使用 Model，它们之间的通信是通过 Presenter （MVC 中的 Controller）来进行的，所有的交互都发生在 Presenter 内部，而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller，从而避免了 View 和 Model 之间的耦合。
扩展：
1. MVVM架构


2. 富互联网应用（RIA）


3. 分布式架构
客户机/服务器系统开发时可以采用不同的分布式计算架构：

分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上（类似三层CS架构的两层应用）；
分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机（类似两层CS架构）；
分布式数据和应用架构数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机（类似三层CS架构）。

4. ANSI
在ANSI/IEEE 1471-2000标准中，系统是为了达成利益相关人（Stakeholder）的某些使命（Mission），在特定环境（Enviroment）中构建的。每一个系统都有一个架构（Architecture）。架构（Architecture）是对所有利益相关人的关注点（Concern）的响应和回答，通过架构描述（Architecture Description）来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。架构描述（Architecture Description）本质上是多视图的。每一个视图（View）是从一个特定的视角（Viewpoint）来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。视角（Viewpoint）的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。一个视图（View）包括一个或者多个架构模型（Model），一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。
5. 需求和架构
需求和软件架构设计面临的是不同的对象：一个是问题空间；另一个是解空间。保持两者的可追踪性和转换，一直是软件工程领域追求的目标。
6. 架构风格和设计模式的区别


架构风格往往是从全局的角度来考虑问题，他是一种独立于实际问题的通用组织结构。例如，常用的B/S架构，在很多不同的系统中，都有应用。


而设计模式着眼于解决某一特定的局部问题，是一种局部解决方案的应用。例如，在很多的软件系统中，创建对象时，希望有统一的机制对这些对象的创建进行管理，所以出现了工厂模式，创建者模式等设计模式。比如java内存垃圾的回收机制也做成了一种设计模式。


7. 软件架构需求
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
8. 面向构件的编程（COP）
面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP 定义如下（Szyperski，1995）： “面向构件的编程需要下列基本的支持：

多态性（可替代性）；
模块封装性（高层次信息的隐藏）；
后期的绑定和装载（部署独立性）；
安全性（类型和模块安全性）。”

系统构件组装分为三个不同的层次：定制（ Customization）、集成（Integration）、扩展（Extension）。这三个层次对应于构件组装过程中的不同任务。
9. OMG接口定义语言IDL
IDL 是一种接口定义语言，具体的定义会涉及到接口以及相关部分。文件包含的主要元素有：接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。
由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为Java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包  (Package)或C++的namespaces。
9. 扩展知识
一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例，其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格，以文本形式输入的代码被逐步转化为各种形式，最终生成可执行代码。早期的编译器采用管道-过滤器架构风格，并且大多数编译器在词法分析时创造独立的符号表，在其后的阶段会不断修改符号表，因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格，主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格，分析树是在语法分析阶段结束后才产生作为语义分析的输入，分析树是数据中心中重要的共享数据，为后续的语义分析提供了帮助。

下面内容来自《软件架构设计》，是我的学习笔记。
  
成功的软件架构设计具有的品质：
  
1、 良好的模块化：每个模块职责清晰，模块之间松耦合，模块内部高聚合并合理的实现了信息隐藏（抽象，封装，信息隐藏）。
  
2、 适应功能需求的变化，适应技术的变化：应该保持应用相关模块和领域通用模块的分离，技术平台相关模块和独立于具体技术的模块相分离，从而达到“隔离变化”的效果。
  
3、 对系统的动态运行有良好的规划：标识出那些事主动模块，那些事被动模块——面向对象中往往是主动类和被动类，明确这些模块之间的调用关系和加锁策略，并说明关键的进程、线程、排队、消息等机制。
  
4、 对数据的良好的规划：不仅包括数据持久化的存储方案，还可能包括数据的传递、数据复制和数据同步策略。
  
5、 明确、灵活的部署规划：还往往涉及到可移植性、可伸缩性、持续可用性和互操作性等大型企业软件特别关注的质量属性的架构策略。
  
合适的才是最好的。设计是一个启发式的过程，同样架构设计也是一个启发式的过程。

新年新事，来点轻松的话题。我们调剂一下后再继续讲CAS SSO单点登录吧因为后面的内容全部和代码有关，大家会觉得枯燥。所以今天我们先来点”番外篇“，讲讲什么是架构师，什么是架构这个永恒的话题吧。此篇源出自我在公司内部写的一个PPT，它是用于在公司内部向广大技术人员做普及用的一个资料，而CSDN这边的编辑不支持图文混排的效果，因此一些章节我就直接截取自我的PPT里的内容了，这样可能对大家在阅读上会显得更加生动和活泼一些吧。

架构的定义

先来看看软件架构的普遍定义吧。
一个程序和计算系统软件体系结构是指系统的一个或多个结构。结构中包括软件的构建，构建的外部可见属性以及它们之间的相互关系。
体系结构并非可运行软件。确切的说，它是一种表达，使软件工程师能够：
分析设计在满足规定需求方面的有效性。
在设计变更相对容易的阶段，考虑体系结构可能的选择方案。
降低与软件构造相关联的风险。
软件架构的生命周期

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

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

软件架构的重要性

为什么说一个软件架构是很重要的呢？直接编程直接开发，多EASY？请看下面几点：
软件架构能够满足系统的品质
架构设计使受益人达成一致的目标
架构设计能够支持计划编制过程
架构设计对系统开发的指导性
架构设计能够有效地管理复杂性
架构设计为复用奠定了基础
架构设计能够降低维护费用
架构设计能够支持冲突分析
什么是好的软件架构

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


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

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

什么又是糟糕的架构



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

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

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

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

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



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


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

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


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

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

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

架构之美

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

架构就像是迷踪拳

动作轻灵敏捷,灵活多变

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



架构就像是独孤九剑


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




架构就像是一件艺术珍品

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



大家知道这幅画吗？他是挪威画家蒙克的一幅作品叫”呐喊“，蒙克这个人是一个疯子，这幅画很简单，就是随手涂鸦一般，但是大家可知道这幅画值多少钱吗？2012年该画在纽约苏富比拍卖上以1.19亿美元被拍卖。

架构的意境

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




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



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项目开发之七宗罪。
第一宗罪：重业务不重技术
第二宗罪：编程开发人员沦为业务开发人员、沦为码农
第三宗罪：IT市场沦为自由市场、小菜场一样的叫买
第四重罪：技术无用论的诞生
第五宗罪：闭门造车，与实际脱节，完全抛弃业务
第六宗罪：消极怠工 
第七宗罪：不思进取
架构师的分类

一般会把架构师分为：

业务架构师即BA
系统架构师SA
其实从严格意义上业说架构师是可以分成三类的：



一般就是把系统架构师和应用架构师合成一类。这个从本质上来讲倒没有什么太大的区别，不伤大雅。

架构师会做什么

一个架构师在一个团队中或者说在一个企业中它具体要做哪些日常工作呢？


架构师并不是万能的

架构师很牛B，可是架构师也是人，他不是超人。


架构师需要掌握的软技巧

技术，是架构师的Hard Skill，那么架构师的Soft Skill有哪些呢？




架构师不是皇冠上的明珠

大家一定一定要记住，架构师决不是像大家想像中的那样，是所谓的皇冠上的明珠，架构师承担的责任是相当的大的。


如何成为架构师

人类是如何进化的？

学习、使用工具、社会协作性、不断的总结经验。

架构师也会退化到比一般的程序员都不如
如果停止了学习的步伐，那么。。。。。。


谈架构师的自我修养

学习之道

需要掌握的基本功中的基本功



大家注意，上面这个列表在学习时是有先后顺序的，从上至下分别为第一步，第二步，第三步。。。。。。不要觉得枯燥，你可以去试试，真的，被折腾着和被快乐着。
Bad artist copy good artist steal


放正你的心态

不断的需要自我激励

成功的唯一方法便是，承认现实，超越现实，鼓起勇气并善用它。

学会平静的对待生活中的不完美之处，适应自己的情绪，了解如何让它们自然宣泄出去
学习如何把不完美的地方转换成我们的优势，激发我们的创造力
自我激励，不管外部条件是否有激励性，找到一种激发最佳状态的情绪，学习如何在我们的意识中制造一些波动来激励我们前进

此文献给开春后工作的众IT技术人员和那些将要或想要走上IT道路的朋友们，祝大家新年新事，工作和学习顺利，最后我还将在2015年继续我的博客写作。
                                                                                                                                                                                                                        --吾以吾血荐中华之IT。