Large website technical architecture

In order to save costs, early websites are generally designed as a centralized system, and applications, databases, etc. are all deployed on one server. However, with the rapid development of the business, bottlenecks gradually appear. According to certain principles (application splitting, service splitting, data splitting, and application decoupling), the transformation to a distributed system involves the following transformations.

main link

• Business splitting: Split the entire website business into different applications, each application is deployed and maintained independently, and the applications communicate through RPC or message queues.

• Clustering (application servers; RPC-based microservice applications, etc.)

• LVS load balancing, responsible for forwarding requests to different business clusters

• Reverse proxy server, commonly used such as Nginx

• Application server, servlet container such as tomcat

• Application and data services are separated and deployed on different servers

• Back-end applications are reasonably layered, usually divided into presentation layer or gateway layer, business logic layer, and data persistence layer

• cache. Divided into two types: local cache; distributed cache

• CDNization. Static content is deployed to CDN and obtained nearby to speed up website response.

• Database read and write separation. The database adopts master-slave hot standby, the application server accesses the master database when writing data, and the master database synchronizes data updates to the slave database through the master-slave replication mechanism.

• Sub-database and sub-table, introducing distributed data framework

• Introduce NoSQL to support massive data storage

• With the help of open source search engines such as elastics search

• Asynchronous, system decoupling.

• Shorten business processes and speed up website access

• Eliminate concurrent access spikes

Five elements of architecture:

• high performance

• Availability

• Scalability

• Extensibility

• safety

1. High performance

The main performance test indicators are:

• Response time: refers to the time it takes for an application to perform an operation

• Concurrency: refers to the number of requests that the system can process at the same time

• QPS: refers to the number of requests processed by the system per unit time

• System performance counters: some data indicators that describe server or operating system performance

Performance optimization, according to the hierarchical structure of the website, can be divided into three categories:

• Web front-end performance optimization

• reduce http requests

• Use browser cache

• enable compression

• CSS at the top of the page, JavaScript at the bottom of the page

• Reduce cookie transmission

• Application server performance optimization: the main means are cache, cluster, asynchronous

• Multithreading (designed to be stateless, using local objects, concurrent access to resources using locks)

• Resource reuse (singleton, object pool)

• data structure

• Asynchronous operations (message queues, peak shaving)

• 多台应用服务器组成一个集群共同对外服务，提高整体处理能力。

• 使用 CDN，将网站静态内容分发至离用户最近的网络服务商机房，使用户通过最短访问路径获取数据。可以在网站机房部署反向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力

• 应用服务器端，可以使用服务器本地缓存和分布式缓存(网站性能优化第一定律：优化考虑使用缓存优化性能)

• 代码层面，也可以通过使用多线程、改善内存管理等手段优化性能。

• 数据库服务器端，索引、缓存、SQL 优化等性能优化手段

• NoSQL 数据库通过优化数据模型、存储结构、伸缩特性等

• 存储服务器性能优化

• 机械硬盘 vs. 固态硬盘

• B+ 树 vs. LSM 树

• RAID vs. HDFS

2、高可用

高可用的网站架构：目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问，主要手段数据和服务的冗余备份及失效转移

• 高可用的应用：显著特点是应用的无状态性

• 通过负载均衡进行无状态服务的失效转移

• 应用服务器集群的 Session 管理

• 高可用的服务：无状态的服务，可使用类似负载均衡的失效转移策略，此外还有如下策略

• 超时设置

• 异步调用

• 服务降级

• 限流

• 高可用的数据：主要手段是数据备份和失效转移机制

• 失效确认

• 访问转移

• 数据恢复

• 冷备：缺点是不能保证数据最终一致和数据可用性

• 热备：分为异步热备和同步热备

• 数据一致性(Consisitency)

• 数据可用性(Availibility)

• 分区耐受性(Partition Tolerance)

• CAP 原理

• 数据备份

• 软件质量保证

• 自动化测试

• 预发布验证

• 灰度发布

• 网站实时监控

• 警报系统

• 自动优雅降级

• 用户行为日志采集（服务器端和客户端）

• 服务器性能监控

• 监控数据采集

• 监控管理

3、伸缩性

大型网站需要面对大量用户的高并发访问和存储海量数据，不可能只用一台服务器就处理全部用户请求，存储全部数据。网站通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。

衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总的服务器数量是否有限制。

对于应用服务器集群，只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入服务器。

对于缓存服务器集群，加入新的服务器可能会导致缓存路由失效，进而导致集群中大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新预热，但是如果应用已经严重依赖缓存，可能会导致整个网站崩溃。需要改进缓存路由算法保证缓存数据的可访问性。

关系数据库虽然支持数据复制，主从热备等机制，但是很难做到大规模集群的可伸缩性，因此关系数据库的集群伸缩性方案必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。

至于大部分 NoSQL 数据库产品，由于其先天就是为海量数据而生，因此其对伸缩性的支持通常都非常好，可以做到在较少运维参与的情况下实现集群规模的线性伸缩。

概括起来伸缩性的分为如下几个方面：

• 应用服务器集群的伸缩性设计

• 轮询(Round Robin, RR)

• 加权轮询(Weighted Round Robin, WRR)

• 随机(Random)

• 最少链接(Least Connections)

• 源地址散列(Source Hashing)

• DNS 域名解析负载均衡

• 反向代理负载均衡(在 HTTP 协议层面，应用层负载均衡)

• IP 负载均衡(在内核进程完成数据分发)

• 数据链路层负载均衡(数据链路层修改 mac 地址，三角传输模式，LVS)

• 分布式缓存集群的伸缩性设计

• Memcached 客户端（包括 API，路由算法，服务器列表，通信模块）

• Memcached 服务器集群

• 分布式缓存的一致性 Hash 算法(一致性 Hash 环，虚拟层)

• 数据存储服务集群的伸缩性设计

• 关系数据库集群的伸缩性设计

• NoSQL 数据库的伸缩性设计

4、可扩展

系统架构设计层面的“开闭原则”，构建可扩展的网站架构

• 利用分布式消息队列降低耦合性

• 分布式消息队列

• 事件驱动架构(Event Driven Architecture)

• 利用分布式服务打造可复用的业务平台

• 分布式服务框架设计(Thrift，Dubbo)

• 可扩展的数据结构(如 HBase的 ColumnFamily 设计)

• 利用开放平台建设网站生态圈

5、网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段，此外还包括 CSRF,Session 劫持等手段。

• 攻击与防御

  对js转义，使其失去执行功能，只作为纯字符串展示

  防范：httpOnly;增加token校验;通过Referer识别。

• 网站安全漏洞扫描

• CSRF 攻击：跨站点请求伪造（Cross Site Request Forgery）

• Error Code

• 表单 Token

• 验证码

• jsonp请求的，Referer 校验

• SQL 注入

• html 危险字符转义

• XSS 攻击：跨站点脚本攻击（Cross Site Script）

 

 

http://mp.weixin.qq.com/s/LRU3wUtRjRWvCoIoyoU5uA