2.性能，在设计架构时候就应该考虑到性能的需求，而不能等到实施编码的时候或测试的时候才注

意。

3.评估的时候还要从用户角度看（交换角色的观点看架构）：主要看使用者的感受，可用性包括两

个层面：

a.组件出现问题的时候如何恢复，B.可用性，结合其他层面（中间件/OS/硬件层面）；同时要

注意在对架构决策平衡的观看架构决策是否合理。

4.从项目管理角度和运营方面评估和审查架构是否可行性：包括时间，成本，服务的重要性 —〉组

件模型，运营模型，未来需求，架构决策

—〉参照用户对服务的列表，服务对组件的矩阵，计划维护的

矩阵（基本的）；组件失败影响分析，详细对用户服务矩阵，组件可行性分析

—〉运营模型，组件模

型，服务水平特征，非功能性需求，现有

IT的环境，架构决策。

5.组件间松耦合(方便处理可用性)和紧耦合（提高性能）的决策，同时要检查容错性。

6.性能架构师的估算和建模：初步估算，不断增加细节，应用设计更改，从技术方案原形获取的信

息，配置更改，容量信息，数据库设计进化，数据库使用模式（同步，备份，容量），应用使用场景建
立，从系统测试获取信息，从系统运行过程获取信息。

7.同时要定义性能和容量的测试的标准，必须在架构时候初步获得系统架构的数量级极点（最高，

最低，弱点，峰值）在测试的标准必须订立和找出系统的系统明显性能慢下来的点，系统崩溃临界点
（这样可以找出系统的在不同状态的临界值，更能把握架构是否合符需求）。正常工作（或者在比例较
多的时候

—时间比例尽可能大）在极限值临界值订立标准有：CPU最大值75%左右，硬盘使用率40%，

网络使用率

30%作用。

8.从系统架构生命周期来考虑架构（非功能性需求，产品的生命周期）这个包括业务的（业务变更

扩展处理张力）和非业务的（物理逻辑扩展处理张力）；可以通过以下步骤：

a.需求和限制条件（系统

关系图和描述来看）

-〉架构功能方面考虑（组件模型和功能规范）-〉数据模型（数据库接口内容，信息

载体内容）

-〉系统运营架构方面考虑（非功能性，安全，网络，应用部署，数据管理，系统管理等

等）

-〉系统运营架构外部接口（组件整合规范）-〉系统性能方面-〉系统可用性（包括硬件，网络，系

统功能，业务）

-〉系统可靠性（备份和恢复，注意业务上应用场景德恢复）-〉项目的团队的实施能力

（项目管理和运营管理的资源环境）

总之，如果可能，希望在我们的项目评估中引进这些方法，以更能准确评估一个系统的可行性以

及能力。

1.5 架构的模式

这部分个人感觉对架构的描述和标示架构方法这部分有些体会：

对于架构设计的描述和方法，目前采用四个视图、一个场景方式，其中大家对进程视图比较关注，因

为我们一般开发人员更多关注逻辑视图和开发视图，而物理视图一般是系统工程师比较关注的，我们感
觉对于大多数项目来说，都没有做到，如果做到对进程模型的把握几乎就能够对整体系统架构软、硬件
的把握，可以很清楚系统的瓶颈之所在。因此，在以后的工作中希望能够加强这一部分工作。

机密

                                                                                                               第 3 页，共 3 页