WEB架构中五个重要的核心指标，分别是性能、可用性、伸缩性、扩展性和安全性这5个架构指标；css
1、性能
性能就是核心要素之一，否则我为何架构设计？随随便便一个lowlow的系统上线就行了。因此性能优化是不少小公司卖不去过的坎。这么说吧，固然优化网站性能的手段也很是多：前端
（1）web前端性能优化：
浏览器访问优化（浏览器缓存、页面压缩传输、合理布局页面、减小Cookie传输）mysql
减小http请求。避免创建太多通信链路。将js、css、图片文件尽量合并。避免太多请求。同时，对于系统的后端请求也尽量进行合理的设计，来避免出现太多交互。nginx
使用浏览器的缓存。http头设置Cache-Control和Expires.js文件名好比能够带时间戳。一旦有更新则更新时间戳，不然缓存；同时尽可能避免同一时间更新大量静态资源。web
对静态资源进行压缩。sql
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.分布式缓存（网站性能优化的第必定律：优先考虑使用缓存优化性能）
通常来讲，存入cache的数据的读写比在2:1以上；且应该是热点数据。
须要考虑若是采用缓存则可能带来的数据短时间内的不一致，或者若是实时更新缓存可能带来的性能和资源开销。
须要考虑cache一旦失效，大量请求直接命中DB可能带来的服务性能雪崩。因此能够对cache采用集群化部署，以此避免丢失过多数据形成服务压力陡增。
对于热点数据考虑进行缓存的预热加载。好比高峰期来临前，先将热点数据提早存入缓存。以此提升高峰期的服务性能。
为了不恶意攻击，一直query不存在的数据，致使cache没法命中而频繁访问DB，能够将不存在的数据也进行缓存并按期清理。同时有机制对恶意请求进行识别和封禁。
分布式缓存应该去中心化并集中管理。经过不一样实例间的互不通讯和同构来保证可扩展性，并下降系统复杂度。
2.异步化（任何能够晚点作的事情都应该晚点再作，感受像懒加载）
经过分布式消息队列来实现削峰的目的。经过业务配合技术来解决问题。好比12306的排队。
3.集群
采用集群也是服务虚拟化的一个体现。用以免单点问题，同时提供更加高可用，高性能的服务。
4.代码优化
多线程中，若是是密集型计算，线程数不宜超过CPU核数。若是是IO处理，则线程数=[任务执行时间/(任务执行时间-IO等待时间)] * CPU核数。除此以外，咱们应该将对象设计成无状态对象，多采用局部对象，适当将锁细化。
进行资源复用。好比采用单例模式，好比采用链接池。
合理设置JVM参数，以最大程度避免不合理的full gc。
5.存储性能优化
关系型数据库的索引采用B+树进行实现。而不少的nosql数据库则采用了LSM树进行存储。LSM在内存中保留最新增删改查的数据，直到内存没法放下，则与磁盘的下一级LSM树进行merge。因此对于写操做较多，而读操做更多的是查询最近写入数据的场景，其性能远高于b+树；采用HDFS结合map reduce进行海量数据存储和分析。其能自动进行并发访问和冗余备份，具备很高的可靠性。其等因而实现了RAID的功能。
（3）数据库层优化：
数据库层实际上是最脆弱的一层，通常在应用设计时在上游就须要把请求拦截掉，数据库层只承担“能力范围内”的访问请求，因此，咱们经过在服务层引入队列和缓存，让最底层的数据库高枕无忧。可是若是请求激增,仍是有大量的查询压力到MySQL,这个时候就要想办法解决MySQL的瓶颈了，这时候可用使用索引、缓存、SQL性能优化等手段，还可使用NoSQL数据库来优化数据模型、存储结构等。详细内容可关注后查看个人【mysql优化专题】，共12篇，已完结。
（4）衡量网站性能的指标（重要的有响应时间、TPS、系统性能计数器等，经过这些指标以肯定系统设计是否达到目标）
响应时间。
并发数。若是暂时没有对应的准确监控，针对不一样业务模型，能够有不同的并发数的预估。咱们的系统进行峰值并发数预估的话，有一种比较粗略的计算方式，即全天请求平均每秒并发数 * 3。但也须要case by case。
吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）以及TPS（每秒处理事务数）。
性能计数器。包括系统负载、线程数、cpu、内存使用状况等。能够用top、free、cat /proc/cpuinfo等命令来查看。系统负载的定义为当前被CPU执行的线程数/等待被CPU执行的总线程数。当其值与逻辑cpu个数相同时是最佳状态，其表明全部的资源都被最大限度地被利用。但也有人认为当负载为0.7倍逻辑CPU数时最佳。
（5）高可用：包括高可用的应用、高可用的服务、高可用的数据和服务于高可用的监控等;
2、安全性
互联网是开放的，任何人在任何地方均可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
安全的5个要素：机密性、完整性、可用性、可控性和可审查性。
1.安全系统架构
安全服务是指计算机网络提供的安全防御措施，包括认证服务、访问控制、数据机密性服务、数据完整性服务和不能否认服务。
特定的安全机制是用来实施安全服务的机制，包括加密机制、数据签名机制、访问控制机制、数据完整性机制、认证交换机制、流量填充机制、路由控制机制和公证机制。
广泛性的安全机制不是为任何特定的服务而特设的，属于安全管理方面，分为可信功能度、安全标记、事件检测、安全审计跟踪和安全恢复。
2.安全保护等级
用户自主保护级
系统审计保护级
安全标记保护级
结构化保护级
访问验证保护级
衡量网站安全架构的标准就是针对现存和潜在的各类攻击和窃密手段，是否有可靠的应对策略。
3、可用性
衡量一个系统架构设计是否知足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各类不可预期的问题时，系统总体是否依然可用。
通常就三个手段、冗余、集群化、分布式。
网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份，任何一台服务器都不会影响应用的总体能够，一般的实现手段即把多台服务器经过负载均衡设备组成一个集群。
4、可扩性
扩展性（Extensibility）指对现有系统影响最小的状况下，系统功能可持续扩展或提高的能力。表如今系统基础设施稳定不须要常常变动，应用之间较少依赖和耦合，当系统增长新功能时，不须要对现有系统的结构和代码进行修改。这个没啥好说。扩展性依赖于前期良好的架构设计。合理业务逻辑抽象，水平/垂直切割分布式化等等，推荐K8S、微服务架构设计。
网站可扩展架构的主要手段是事件驱动架构和分布式服务。
事件驱动一般利用消息队列实现，经过这种方式将消息生产和处理逻辑分隔开。
服务器服务则是将业务和可复用服务分离开来，经过分布式服务框架调用。新增长产品可用经过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。
对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF可扩展立方 （Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。
X轴扩展 —— 关注水平的数据和服务克隆，也就是前文提到的“加机器解决问题”
Y轴扩展 —— 关注应用中职责的划分，好比数据类型，交易执行类型的划分
Z轴扩展 —— 关注服务和数据的优先级划分，如分地域划分
整个扩展模型，用下图来表示，其中原点表明彻底无扩展的状态。
5、伸缩性
服务尽可能同构。DB、cache在考虑分布式时尽可能提早设计好扩展方案。也能够采用一些主流的对水平伸缩支持较好的Nosql、memcached、hbase等。
（1）横向分离：将不一样的业务模块分离部署，实现系统的伸缩性；
（2）纵向分离：将业务处理流程上得不一样部分分离部署，实现系统的伸缩性；
最后附<WEB架构设计5个核心要素>思惟导图一张：在公众号后台回复“web”获取；
原文连接：
https://blog.csdn.net/guolong1983811/article/details/78636443
K8S培训推荐
Kubernetes线下实战培训，采用3+1新的培训模式（3天线下实战培训，1年内可免费再次参加），资深一线讲师，实操环境实践，现场答疑互动，培训内容覆盖：Docker方面：Docker架构、镜像、数据存储、网络、以及最佳实践。Kubernetes实战内容，Kubernetes设计、Pod、经常使用对象操做，Kuberentes调度系统、QoS、Helm、网络、存储、CI/CD、日志监控等。<了解更多详情>
本文分享自微信公众号 - K8S中文社区（k8schina）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。