1. 软件架构简介

所谓架构，见仁见智，很难有一个明确或标准的定义；但架构并非镜花水月或阳春白雪，有系统的地方就需要架构，大到航空飞机，小到一个电商系统里面的一个功能组件，都需要设计和架构。抽象而言，架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。架构能将目标系统按某个原则进行切分，切分的原则，是要便于不同的角色进行并行工作，结构良好的创造活动要优于毫无结构的创造活动。

软件架构的核心价值，即是控制系统的复杂性，将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图，它描述的对象是直接构成系统的抽象组件；各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。架构师的职责是努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，理解并解析需求，创建有用的模型，确认、细化并扩展模型，管理架构；能够进行系统分解形成整体架构，能够正确的技术选型，能够制定技术规格说明并有效推动实施落地。

一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

1. 架构的核心要素

所谓架构，一种通俗的说法就是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。

而软件架构即“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各方面的设计”。一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

1.1 性能

性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题。也正因为性能问题几乎无处不在，所以优化网站性能的手段也非常多：

在学习架构时，第一步不要去学习框架，而是要学习架构的演进。强烈推荐李智慧老师的《大型网站技术架构》，这本书翻起来很快，对构筑你自己的体系很有帮助，本文的内容来源于它，在此基础上拓展了下

1. 架构演进

大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变得很棘手。大型网站架构主要就是解决这类问题。

架构选型是根据当前业务需要来的，在满足业务需求的前提下，既要有足够的扩展性也不能过度设计，每次的架构升级都是为了解决系统瓶颈而做的。

革命尚未成功，同志们还需努力。需要多揣摩揣摩

TIP

本文整理自朱晔的互联网架构实践心得, 他是结合了 微软给出的云架构的一些模式的基础上加入他自己的理解来总结互联网架构中具体的一些模式。

朱晔：设计模式是前人通过大量的实践总结出来的一些经验总结和最佳实践。在经过多年的软件开发实践之后，回过头来去看23种设计模式你会发现很多平时写代码的套路和OO的套路和设计模式里总结的类似，这也说明了你悟到的东西和别人悟到的一样，经过大量实践总能趋向性得出一些最佳实践的结论。架构设计也是一样，这里结合自己的理解分析一下微软给出的云架构的一些模式。话说微软干这方面的事情真的很厉害，之前翻译过的《微软应用架构指南》写的也很不错。有了模式的好处是，技术人员和技术人员之间的对话可以毫不费力的通过几个模式关键词进行交流，就像现在大家沟通提到职责链模式，如果双方都理解这个模式的意义那么这五个字替代的可能就是半小时的解释。废话不多说，接下去来看一下这些其实已经很熟悉亲切的模式。

架构演进中有很多知识点，总体上可以归结为以下模式，这里说的模式本质是架构中技术点的抽象。

1. 架构的模式

每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作。

所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。为此，在实践中提出了许多解决方案，以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。

1.1 分层

1. 架构安全

对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。对于安全问题，首先要提高安全意识，建立一个安全的有效机制，从政策层面，组织层面进行保障。比如服务器密码不能泄露，密码每月更新，并且三次内不能重复；每周安全扫描等。以制度化的方式，加强安全体系的建设。同时，需要注意与安全有关的各个环节。安全问题不容忽视。包括基础设施安全，应用系统安全，数据保密安全等。

1.1 基础设施安全

硬件采购，操作系统，网络环境方面的安全。一般采用，正规渠道购买高质量的产品，选择安全的操作系统，及时修补漏洞，安装杀毒软件防火墙。防范病毒，后门。设置防火墙策略，建立DDOS防御系统，使用攻击检测系统，进行子网隔离等手段。

在学习架构时，我认为首先要理清楚架构的视角，因为你所认知的架构和别人所说的架构可能是两码事。对于不同职位的视角是不一样的，比如开发而言他更多的看到的是开发架构；对售前人员，他可能更多的看到的是业务架构；对于运维人员，他看到的可能是运维架构；而对于技术支持和部署人员，他更多的看到的网络和物理架构。

1. 架构的视角

在笔者的知识体系中，实际上将架构分为业务架构、应用架构、云基础架构这几大类，业务架构主要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列问题。无论何种架构，都希望能实现系统的可变的同时保障业务的高可用。

容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。故障转移（failover），即当活动的服务或应用意外终止时，快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作。故障恢复是在计划内或计划外中断解决后切换回主站点的过程。

1. 什么是容灾和备份？

容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。

高并发实现的三板斧：缓存，限流和降级。缓存在高并发系统中有者极其广阔的应用，需要重点掌握，本文重点介绍下缓存及其实现。

1. 缓存简介

随着互联网的普及，内容信息越来越复杂，用户数和访问量越来越大，我们的应用需要支撑更多的并发量，同时我们的应用服务器和数据库服务器所做的计算也越来越多。但是往往我们的应用服务器资源是有限的，且技术变革是缓慢的，数据库每秒能接受的请求次数也是有限的（或者文件的读写也是有限的），如何能够有效利用有限的资源来提供尽可能大的吞吐量? 一个有效的办法就是引入缓存，打破标准流程，每个环节中请求可以从缓存中直接获取目标数据并返回，从而减少计算量，有效提升响应速度，让有限的资源服务更多的用户。

高可用性对于我们来说应该属于经常提到的名词，本文我们将介绍在分布式系统中保证高可用性的一些常用经验。系统可用性指标系统可用性指标简单来将就是系统可用时间与总运行时间之比Availability=MTTF/(MTTF+MTTRMTTF)MTTF 是 Mean Time To Failure，指平均故障前的时间，即系统平均能够正常运行多长时间才发生一次故障。系统的可靠性越高，MTTF 越长(简...

高可用性对于我们来说应该属于经常提到的名词，本文我们将介绍在分布式系统中保证高可用性的一些常用经验。