一、性能

性能就是核心要素之一，不然我为什么架构设计？随随便便一个lowlow的系统上线就好了。所以性能优化是很多小公司卖不去过的坎。这么说吧，当然优化网站性能的手段也非常多：

（1）web前端性能优化：

1. 浏览器访问优化（浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输）

• 减少http请求。避免建立太多通讯链路。将js、css、图片文件尽可能合并。避免太多请求。同时，对于系统的后端请求也尽可能进行合理的设计，来避免出现太多交互。
• 使用浏览器的缓存。http头设置Cache-Control和Expires.js文件名比如可以带时间戳。一旦有更新则更新时间戳，否则缓存；同时尽量避免同一时间更新大量静态资源。
• 对静态资源进行压缩。
• css放置在页面最上方，js放下最下面。以提前进行css渲染。同时避免js带来的页面阻塞。但需要case by case。比如页面dom节点需要依赖js生成，则可视情况改变文件位置。
• 减少cookie传输。同时让静态资源有独立域名，发送静态资源请求时候不发送cookie。以此减少传输代价。cookie可以通过document.cookie获取。

2.CDN加速

• 缓存图片、文件、CSS以及script脚本。但是pc上的CDN加速效果要好于移动端。经过调研发现，last-mile的延迟越高，CDN的相对有效性越差（具体见文章为什么CDN对移动客户端加速“没有”效果）。

 

3.反向代理

• 可以提供七层负载均衡（http请求进行均衡策略），并且可以提供静态资源的缓存，请求转发，防止网络攻击等。比较流行的有Nginx。

 

（2）应用服务器性能优化：

如果请求静态界面不卡了,但是动态数据还是卡,说明MySQL处理的请求太多了,可以使用服务器本地缓存和分布式缓存，也可以通过异步操作方式来加快响应，在高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能，具体如下：

1.分布式缓存（网站性能优化的第一定律：优先考虑使用缓存优化性能）

1. 一般来说，存入cache的数据的读写比在2:1以上；且应该是热点数据。
2. 需要考虑如果采用缓存则可能带来的数据短期内的不一致，或者如果实时更新缓存可能带来的性能和资源开销。
3. 需要考虑cache一旦失效，大量请求直接命中DB可能带来的服务性能雪崩。所以可以对cache采用集群化部署，以此避免丢失过多数据造成服务压力陡增。
4. 对于热点数据考虑进行缓存的预热加载。比如高峰期来临前，先将热点数据提前存入缓存。以此提高高峰期的服务性能。
5. 为了避免恶意攻击，一直query不存在的数据，导致cache无法命中而频繁访问DB，可以将不存在的数据也进行缓存并定期清理。同时有机制对恶意请求进行识别和封禁。
6. 分布式缓存应该去中心化并集中管理。通过不同实例间的互不通信和同构来保证可扩展性，并降低系统复杂度。

2.异步化（任何可以晚点做的事情都应该晚点再做，感觉像懒加载）

通过分布式消息队列来实现削峰的目的。通过业务配合技术来解决问题。比如12306的排队。

3.集群

采用集群也是服务虚拟化的一个体现。用以避免单点问题，同时提供更加高可用，高性能的服务。

4.代码优化

1. 多线程中，如果是密集型计算，线程数不宜超过CPU核数。如果是IO处理，则线程数=[任务执行时间/(任务执行时间-IO等待时间)] * CPU核数。除此之外，我们应该将对象设计成无状态对象，多采用局部对象，适当将锁细化。
2. 进行资源复用。比如采用单例模式，比如采用连接池。
3. 合理设置JVM参数，以最大程度避免不合理的full gc。

5.存储性能优化

关系型数据库的索引采用B+树进行实现。而很多的nosql数据库则采用了LSM树进行存储。LSM在内存中保留最新增删改查的数据，直到内存无法放下，则与磁盘的下一级LSM树进行merge。所以对于写操作较多，而读操作更多的是查询最近写入数据的场景，其性能远高于b+树；采用HDFS结合map reduce进行海量数据存储和分析。其能自动进行并发访问和冗余备份，具有很高的可靠性。其等于是实现了RAID的功能。

（3）数据库层优化：

1. 数据库层其实是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求，所以，我们通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。但是如果请求激增,还是有大量的查询压力到MySQL,这个时候就要想办法解决MySQL的瓶颈了，这时候可用使用索引、缓存、SQL性能优化等手段，还可以使用NoSQL数据库来优化数据模型、存储结构等。详细内容可关注后查看我的【mysql优化专题】，共12篇，已完结。

 

（4）衡量网站性能的指标（重要的有响应时间、TPS、系统性能计数器等，通过这些指标以确定系统设计是否达到目标）

1. 响应时间。
2. 并发数。如果暂时没有对应的准确监控，针对不同业务模型，可以有不一样的并发数的预估。我们的系统进行峰值并发数预估的话，有一种比较粗略的计算方式，即全天请求平均每秒并发数 * 3。但也需要case by case。
3. 吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）以及TPS（每秒处理事务数）。
4. 性能计数器。包括系统负载、线程数、cpu、内存使用情况等。可以用top、free、cat /proc/cpuinfo等命令来查看。系统负载的定义为当前被CPU执行的线程数/等待被CPU执行的总线程数。当其值与逻辑cpu个数相同时是最佳状态，其代表所有的资源都被最大限度地被利用。但也有人认为当负载为0.7倍逻辑CPU数时最佳。

（5）高可用：包括高可用的应用、高可用的服务、高可用的数据和服务于高可用的监控等，关于高可用，我还是决定开个单章讲解

 

 

 

二、安全性

互联网是开放的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

安全的5个要素：机密性、完整性、可用性、可控性和可审查性。

1、安全系统架构

1）安全服务是指计算机网络提供的安全防护措施，包括认证服务、访问控制、数据机密性服务、数据完整性服务和不可否认服务。

2）特定的安全机制是用来实施安全服务的机制，包括加密机制、数据签名机制、访问控制机制、数据完整性机制、认证交换机制、流量填充机制、路由控制机制和公证机制。

3）普遍性的安全机制不是为任何特定的服务而特设的，属于安全管理方面，分为可信功能度、安全标记、事件检测、安全审计跟踪和安全恢复。

2、安全保护等级

1）用户自主保护级

2）系统审计保护级

3）安全标记保护级

4）结构化保护级

5）访问验证保护级

衡量网站安全架构的标准就是针对现存和潜在的各种攻击和窃密手段，

 

 

是否有可靠的应对策略。

三、可用性

衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。

一般就三个手段、冗余、集群化、分布式。

网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份，任何一台服务器都不会影响应用的整体可以，通常的实现手段即把多台服务器通过负载均衡设备组成一个集群。

 

 

四、扩展性

扩展性（Extensibility）指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。这个没啥好说。扩展性依赖于前期良好的架构设计。合理业务逻辑抽象，水平/垂直切割分布式化等等。

网站可扩展架构的主要手段是事件驱动架构和分布式服务。

事件驱动通常利用消息队列实现，通过这种方式将消息生产和处理逻辑分隔开。

服务器服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增加产品可用通过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。

对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF可扩展立方 （Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

• X轴扩展 —— 关注水平的数据和服务克隆，也就是前文提到的“加机器解决问题”
• Y轴扩展 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分
• Z轴扩展 —— 关注服务和数据的优先级划分，如分地域划分

整个扩展模型，用下图来表示，其中原点代表完全无扩展的状态。

 

 

五、伸缩性

服务尽量同构。DB、cache在考虑分布式时尽量提前设计好扩展方案。也可以采用一些主流的对水平伸缩支持较好的nosql、memcached、hbase等。

（1）横向分离：将不同的业务模块分离部署，实现系统的伸缩性；

 

 

（2）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性；