To Be an Architect : 一句话架构
1.1 架构的目的
创造一个架构，来支持服务级需求（service-levelrequirements）或商业级需求，
避免不必要的技术风险，让系统在预设的限定和假设中可靠工作。
1.2 架构肯定要做的几个事情
第一．分解（Decomposition）。分解为粗粒度的子系统；分解为细粒度的组件。化繁为简。
第二．接口（Interface）。系统被分解的同时，必须要考虑分解后的接口。无接口不成整体。
第三．协作（Collaboration）。通过行为和结构角度的考虑，通过接口，把分解的子系统，
组件重新组成了一个有机整体。
第四．权衡（Trade-off）。从性能，重用，技术可行性，实现代价，经济性，甚至用户心理学，美学的角度做考虑。
1.3 关于架构师这个角色
领导力
领导和推动开发团队按照既定的技术架构路线完成系统的中枢神经。
沟通能力
第一：调研需求。
第二：善于通过书面和口语来记录和表达系统蓝图。
第二：说服团队内外的主要项目干系人。
第三：指导开发团队。
1.4 识别服务级需求（service-level (QoS)requirements），关于那些-bility的需求
（做人不能一直靠装Bility，做系统更加不能没Bility靠装Bility.）
主要的那些--bility
Performance,Scalability,Reliability,Availability,Extensibility,Maintainability,Manageability andSecurity.
1.4.1 性能performance
响应时间response time：特定终端的响应时间.
例如:每个报表请求到显示的时间不超过5秒。
事务吞吐量transaction throughout
例如:一秒钟能同时处理一千个订单付款请求。
1.4.2 可伸缩性Scalability
指在不改变（软件）系统的前提下，继续保证系统响应和满足服务的能力(QoS)。
“可伸缩性的度量是向系统中增加资源（通常是硬件）对系统性能的影响”――Martin Flower
系统能力capacity of asystem
系统能在保持QoS的前提下，可以处理的最大的进程事务数量.
水平伸缩horizontalscaling of the hardware
水平伸缩：让系统看上去就像运行在一个机器那样的运行在多个机器上。
云计算和虚拟化技术的兴起，让水平伸缩这个原本复杂的问题变得简单了。
在这个问题变得简单以前，垂直伸缩（vertical scaling）当然是更自然的选择。
关于垂直伸缩（vertical scaling）的古老寓言：PC服务器不行，就换小型机…
1.4.3 可靠性reliability
关于可靠性的简单例子：
只要系统的某个特定功能点的要求是按照某种条件下1+1=3设计的，那么只要满足特定条件，1+1=3就会出现（持续性Consistency）。
不符合出现1+1=3的情况下，就要保证1+1=3不出现（Integrity 完整性）。
1.4.4 可用性Availability
可用性是系统提供持续（Continuous）服务的能力。
可用性=系统运行时间/（系统运行时间+系统停机时间）。
最可用--99.999%（大型机等），较可用--99%（个人电脑）
对于可用性的测量，一定要从用户的观点出发。
1.4.5 可扩展性Extensibility
可以在不影响现有系统功能运作的情况下，增加特定的新功能或者修改某些功能。
系统可扩展性要求的根源：
用户变化；
系统平台变化；
制度流程变化;
业务量变化；
业务需求变化:如，货币种类，汇率变化了。
可扩展性设计的一些例子，如：
1.数据库字段值至少要在需求的基础上放大50%以上。
2.超容量设计。
3.把常量表独立在程序之外。
其他关于可扩展性涉及的一些常见观点：低耦合（Low Coupling），针对接口开发（Interface），封装（Encapsulation）
1.4.6 可维护性Maintainability
在修正现有的系统缺陷时候，不影响到现有系统的其他功能。
例子：
1.采用标准的出错术语。
2.尽可能的提供发生的问题，原因，影响，以及如何改进的信息。
3.上下文相关的帮助。
4.完善技术资料（手册，配置图标，资源标签加注）。
5.安装补丁入口。
1.4.7 可管理性Manageability
管理系统，并保证系统Qos能力的能力。
可管理性的一个前提：能够监控系统行为。
1.4.8 安全性Security
安全是有代价的。
不管是什么层面安全需求的系统，安全的最起码的要求是不能因为用户的非恶意误操作而趴下。
本文出自 “海德-技术笔记” 博客，转载请与作者联系！