架构中五个重要的核心指标：性能、可用??性、可扩展性、可扩展性和安全性。1.性能性能是核心要素之一，不然我为什么要设计架构？低级系统上网就行了。所以，性能优化是很多小公司卖不出去的一道坎。这么说吧，当然优化网站性能的方法有很多：（1）Web前端性能优化：浏览器访问优化（浏览器缓存、页面压缩传输、合理的页面布局、减少cookie传输）减少http请求.避免建立过多的通信链接。js、css、图片文件尽量结合起来。避免请求过多。同时，尽可能合理地设计系统的后端请求，避免过多的交互。使用浏览器的缓存。httpheader设置Cache-Control和Expires.js文件名，例如，可以有时间戳。一旦有更新，更新时间戳，否则缓存；同时尽量避免同时更新大量的静态资源。压缩静态资源。css放在页面顶部，js放在底部。提前CSS渲染。同时避免js造成的页面阻塞。但需要具体情况。比如页面dom节点需要依赖js生成，可以根据情况更改文件位置。减少cookie传输。同时静态资源有独立的域名，发送静态资源请求时不发送cookie。这降低了传输成本。Cookies可以通过document.cookie获取。2、CDN加速缓存图片、文件、CSS和script脚本。但是PC端的CDN加速效果要好于移动端。经过调查发现，最后一公里延迟越高，CDN的相对效果越差（详见文章为什么CDN对移动客户端加速“没有”效果）。3、反向代理可以提供七层负载均衡（http请求均衡策略），可以提供静态资源缓存、请求转发、防止网络攻击。比较流行的是nginx。(2)应用服务器性能优化：如果请求的静态接口没有卡住，但是动态数据还是卡住了，说明MySQL处理的请求太多了。可以使用服务器的本地缓存和分布式缓存，或者使用异步操作来加速响应，在高并发请求的情况下，可以将多个应用服务器组成一个集群共同对外服务，提高整体处理能力，并且提高性能，具体如下：1.分布式缓存（网站性能优化规律：优先使用缓存来优化性能）一般来说，缓存中存储的数据的读写比在2:1以上；它应该是热点数据。需要考虑缓存可能导致的数据的短期不一致，或者实时更新缓存可能带来的性能和资源开销。需要考虑一旦缓存失效可能导致大量请求导致的服务性能雪崩。因此缓存可以采用集群部署，避免数据丢失过多导致业务压力骤增。对于热数据，可以考虑预加载缓存。比如在高峰期到来之前，将热点数据提前存储到缓存中。这提高了高峰时段的服务性能。为了避免恶意攻击，查询了不存在的数据，导致缓存频繁访问DB。不存在的数据也可以缓存并定期清理。同时，有识别和阻断恶意请求的机制。分布式缓存应该是分散的，集中管理的。通过不同实例之间的非通信和同构，保证可扩展性，降低系统复杂度。2.通过分布式消息队列实现异步化（能晚做的就晚做，感觉就是懒加载），达到削峰的目的。通过业务与技术的合作解决问题。比如12306的队列。3、使用集群也是服务虚拟化的一个体现。它用于避免单点问题，同时提供更高可用和高性能的服务。4.代码优化在多线程中，如果是密集型计算，线程数不要超过CPU核数。如果是IO处理，线程数=[任务执行时间/（任务执行时间-IO等待时间）]*CPU核数。另外，应该把对象设计成无状态对象，多使用局部对象，适当细化锁。执行资源重用。比如使用单例模式，比如使用连接池。合理设置JVM参数，避免不合理的fullgc。5.存储性能优化关系型数据库的索引是通过B+树实现的。许多nosql数据库使用LSM树进行存储。LSM将增删改查的数据保存在内存中，直到内存放不下，再与磁盘上的下一级LSM树合并。因此写操作多，读操作更多的是查询最近写入的数据，其性能比b+树高很多；HDFS结合mapreduce用于海量数据的存储和分析。可自动进行并发访问和冗余备份，可靠性高。相当于实现了RAID的功能。(3)数据库层优化：数据库层其实是最脆弱的一层。一般在应用设计的时候需要在上游拦截请求。数据库层只承担“力所能及”的访问请求。因此，我们通过在服务层引入队列和缓存，让底层的数据库高枕无忧。但是，如果请求激增，MySQL的查询压力仍然很大，这时候就需要想办法解决MySQL的瓶颈了。这时候可以使用索引、缓存、SQL性能优化等手段，也可以使用NoSQL数据库来优化数据模型。存储结构等，具体可以关注我的【mysql优化专题】，共12篇，已完成。(4)衡量网站性能的指标（重要的包括响应时间、TPS、系统性能计数器等，通过这些指标来判断系统设计是否达到目标）响应时间。并发数。如果暂时没有相应的准确监控，不同的业务模型可能会有不同的并发数预估。如果我们的系统预估峰值并发数，有一个粗略的计算方法，即全天平均每秒的并发请求数*3。但是也需要具体情况具体分析。吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）、TPS（每秒事务数）。性能计数器。包括系统负载、线程数、cpu、内存占用等，可以使用top、free、cat/proc/cpuinfo等命令查看。系统负载定义为CPU当前正在执行的线程数/等待CPU执行的线程总数。当它的值与逻辑cpu个数相同时，就是一个好的状态，也就是说所有的资源都得到了最大程度的利用。但也有人认为负载是逻辑CPU数的0.7倍会更好。（5）高可用：包括高可用的应用、高可用的服务、高可用的数据、高可用的监控服务等。关于高可用，我决定开一个单独的章节来解释2.安全互联网是开放的，谁，任何地方都可以访问该站点。网站的安全架构是为了保护网站免受恶意访问和攻击，保护网站重要数据不被窃取。安全的5个要素：机密性、完整性、可用性、可控性和可审计性。1.安全体系结构1)安全服务是指计算机网络提供的安全保护措施，包括认证服务、访问控制、数据机密性服务、数据完整性服务和不可否认性服务。2）具体的安全机制是用来实现安全服务的机制，包括加密机制、数据签名机制、访问控制机制、数据完整性机制、认证交换机制、流量填充机制、路由控制机制和公证机制。3)通用安全机制不是针对任何特定服务特设的，而是属于安全管理方面的，包括可信功能、安全标记、事件检测、安全审计跟踪和安全恢复。2.安全防护等级1)用户独立防护等级2)系统审计防护等级3)安全标志防护等级4)结构化防护等级5)访问验证防护等级衡量网站安全架构的标准是针对各种现有和潜在的攻击和偷窃手段，是否有可靠的应对策略。3.可用性衡量一个系统架构设计是否达到高可用性的目标，假设当系统中任意一台或多台服务器宕机，以及出现各种意外问题时，系统整体是否仍然可用。一般有冗余、聚类和分布三种方法。网站高可用的主要手段是冗余。应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份。任何服务器都不会影响应用程序的整体性能。通常的实现方式是多台服务器通过负载均衡设备组成一个集群。4.可扩展性可扩展性是指在对现有系统影响最小的情况下，不断扩展或改进系统功能的能力。表现为系统基础设施稳定，不需要频繁变更，应用之间的依赖和耦合较少。系统增加新功能时，无需修改现有系统的结构和代码。对此无话可说。可扩展性取决于前期良好的架构设计。合理的业务逻辑抽象、水平/垂直拆分分布等。网站可扩展架构的主要手段是事件驱动架构和分布式服务。事件驱动通常使用消息队列来实现，通过这种方式将消息的生产和处理逻辑分开。服务器服务将业务与可重用服务分离，通过分布式服务框架调用。新加入的产品可以通过调用可重用的服务来实现自己的业务逻辑，对现有产品没有任何影响。对此，《可扩展的艺术》一书提出了一个更系统的可扩展性模型——AKFScalabilityCube。立方体沿三个坐标轴设置：X、Y、Z。X轴扩展——关注横向数据和服务克隆，也就是前面提到的“加机器解决问题”Y轴扩展——关注应用中的职责划分，比如数据类型、事务执行类型的划分Z-axisexpansion——注意服务和数据的优先级，比如将整个扩展模型按区域划分，如下图，其中原点代表完全没有扩展的状态。5.可扩展的服务应该尽可能的同构。在考虑分布式分布时，DB和cache应该尽量提前设计好扩容方案。也可以使用一些支持水平扩展的主流的nosql、memcached、hbase等。（1）横向分离：将不同的业务模块分离部署，实现系统的可扩展性；(2)垂直分离：将业务流程的不同部分分离部署，实现系统的可扩展性；
