大型网站技术架构（二）核心架构要素

大型网站技术架构（二）核心架构要素

一、概述

除了系统功能外，软件架构还需关注性能、可用性、伸缩性、扩展性、安全这几个架构要素。

1.1性能

衡量网站性能有一些列指标，总要的有：响应时间、TPS、系统性能计数器等。
网站性能优化的手段有很多，从用户浏览器到服务器再到数据库，影响到用户请求的所有环节都可以进行性能优化。
1.浏览器端：
①可以通过压缩、合理布局页面、减少cookie传输，减少http请求的方式减少请求的大小与数量，进而改善性能。
②采用缓存优化：浏览器缓存、CDN加速和反向代理，加快请求响应速度。
2.应用服务器端：
①缓存：本地缓存和分布式缓存
②异步：可采用消息队列解耦削峰。
③集群：多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。
3.数据库服务器端：
关系型：缓存、索引、SQL优化等性能优化手段已经比较成熟。
Nosql：优化数据模型、存储结构、伸缩特性等手段进行性能优化。

1.2可用性

网站宕掉、服务不可用对网站而言是重大事故。网站的高可用架构设计的主要目的就是保证服务器硬件故障或者网站升级时服务依然可用、数据依然保存并能够访问。
1.网站高可用的主要手段是冗余。
①对于应用服务器：多台应用服务器通过负载均衡设备组成集群对外提供服务。任何一台服务器宕机，只需要将请求切换到其他服务器即可（前提是应用服务器不保存会话信息——无状态，第三节详细介绍）。
②对于存储服务器：由于其上存储着数据，需要对数据进行实时备份，服务器宕机时，将数据访问转移到可用的服务器上，并进行数据恢复以保证继续有服务器宕机时数据依然可用。
2.除了运行环境，网站的高可用还需要软件开发过程的质量保证。通过发不验证、自动化测试、自动化发布、灰度发布等手段减少故障、避免故障范围扩大。

1.3伸缩性

所谓伸缩性是指不需要改变网站的软硬件设计仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。如：淘宝“双十一”活动，通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。活动结束后将这些服务器下线以节约成本。
网站的伸缩性设计分为两类：
1.根据功能进行物理分离实现伸缩。纵向分离（分层后分离）/横向分离（业务功能分割后分离）然后部署。
2.单一功能通过集群实现伸缩。
①应用层：
应用服务器集群——选择合适的负载均衡设备向集群中不断加服务器。（前提：服务器不保存数据，即所有服务器都是对等的）
②数据层：
分布式缓存集群——加入新服务器可能导致缓存路由失效，故而改进缓存路由算法保证缓存数据的可访问性。
数据存储服务器集群——包括关系数据库和NoSQL数据库伸缩性设计两类：
》关系数据库集群——虽然支持数据复制、主从热备等机制，但是很难做到大规模集群的可伸缩性。因此其伸缩性必须在数据库之外实现，通过路由分区等手段将部署有多个数据库的服务器组成一个集群。
》Nosql伸缩性设计——对于大部分NoSQL产品，由于其先天为海量数据而生，伸缩性非常好，可以做到在较少运维参与的情况下实现集群规模的线性伸缩

1.4扩展性

所谓扩展性是指，对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。不同于其他架构要素主要关注非功能需求，如何设计网站的架构使其能快速响应需求变化，是网站可扩展架构的主要目的。
设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提高模块的复用性。网站利用分层、分割解耦合，利用分布式部署的方式物理上分离耦合，将模块分布式部署以后的聚合的方式主要包括消息队列和分布式服务。故而，网站可扩展架构的主要手段是：事件驱动架构（通过在低耦合的模块之间传输事件消息，保持模块的松耦合，并借助事件消息的通信完成模块间合作，典型的EDA就是生产者消费者模式）和分布式服务（将业务和可复用服务分离开来，通过分布式服务框架调用）。
1.利用分布式消息队列实现模块间通信，降低系统耦合性；
2.利用分布式服务打造可复用的业务平台

1.5安全

网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。

二、高性能

2.1Web前端优化

1.浏览器访问优化
①减少http请求——具体手段包括合并CSS、合并JS、合并图片等。
②CSS放在页面最上面、JS放在页面最下面——因为浏览器会在下载全部CSS后便对整个页面渲染，在加载完JS后立即执行。
③启用压缩——在服务端对文件进行压缩，浏览器端解压缩，有效减少通信传输的数据量（会对服务器和浏览器产生一定压力）。
④减少cookie传输——减少cookie中传输的数据量；静态资源的访问如CSS、JS等，发送cookie没意义，考虑使用独立域名访问。
⑤使用浏览器缓存——通过HTTP头中的Cache-Control和Expires属性设定缓存，时间可以使数天甚至几个月。更新缓存时采用逐量更新的方法，以免用户浏览器突然大量缓存失效。
2.CDN加速
本质仍是缓存，而且将数据缓存在离用户最近的地方，使用户以最快速度获取数据。CDN一般缓存的是静态资源，如：图片、文件、CSS、Script脚本、静态网页等。
CDN部署在网络运营商的机房，这些运营商又是终端用户的网络提供服务商，因此用户请求第一跳到达了CDN服务器，CDN缓存着请求的数据就直接返回给浏览器，以最短路径返回响应。
3.反向代理
》是什么？
传统代理服务器位于浏览器一侧，代理浏览器将http请求发送到互联网上，反向代理服务器位于网站机房一侧，代理Web服务器接受Http请求。
》怎么样？
①代理服务器通过配置缓存加速Web请求，当用户第一次访问静态内容时，静态内容就被缓存在反向代理服务器上了。事实上，有些网站会把动态内容也缓存在代理服务器上。当这些动态内容有变化时，通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新的动态内容再次缓存起来。
②除了通过缓存提升性能外，反向代理还可以实现负载均衡功能，通过负载均衡构建的应用集群提高系统的总体处理能力。
③反向代理服务器相当于在Web服务器和可能的网络攻击之间建立了一个屏障，有一定的安全功能。

2.2应用服务器性能优化

缓存、异步、集群、代码优化

2.3存储性能优化

1.数据库
关系型：缓存、索引、SQL优化等性能优化手段已经比较成熟。
Nosql：优化数据模型、存储结构、伸缩特性等手段进行性能优化。
2.磁盘介质
在网站应用中，海量数据读写对磁盘访问造成巨大压力，磁盘的可用性和容错性也至关重要
①机械硬盘和固态硬盘
》由于每次访问都要移动磁头臂，机械硬盘有快速顺序读写，慢速随机读写的访问特性。
》固态硬盘数据存储在可持久记忆的硅晶体上，有更好的随机访问特性。
②存储结构。B+树和LSM树
详细内容： https://blog.csdn.net/u013928917/article/details/75912045 B+树和LSM比较
③RAID和HDFS
》RAID（廉价磁盘冗余阵列）主要目标是实现数据在多块磁盘上并发读写和数据备份。
》RAID技术在传统关系数据库及文件系统中应用比较广泛，在大型网站比较喜欢使用的NoSQL以及分布式文件系统中，RAID技术遭到冷落。HDFS（Hadoop分布式文件系统）：系统在整个存储及集群的多态服务器上进行数据读写和备份，可以看做在服务器集群规模上实现了类似RAID的功能，因此不需要磁盘RAID。
①HDFS以块为单位管理文件内容，一个文件被分割成若干个Block，当程序写文件时，每写完一个Block，HDFS就会自动复制到另外两台机器上，保证Block有三个副本。相当于实现了RAID1的数据复制功能。
②对文件进行处理计算时，通过MapReduce并发计算任务框架，可以启动多个计算子任务，同时读取多个Block，并发处理，相当于实现了RAID0的并发访问功能。
》HDFS架构

1、Client：就是客户端。
文件切分。文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
与 NameNode 交互，获取文件的位置信息。
与 DataNode 交互，读取或者写入数据。
2、NameNode：就是 master，它是一个主管、管理者。
管理 HDFS 的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求。
3、DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。
存储实际的数据块。
执行数据块的读/写操作。
4、Secondary NameNode：并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。
辅助 NameNode，分担其工作量。	
定期合并 fsimage和fsedits，并推送给NameNode。
在紧急情况下，可辅助恢复 NameNode。

拓展阅读：
https://www.cnblogs.com/codeOfLife/p/5375120.html 初步掌握HDFS的架构及原理

三、高可用性

网站的可用性描述网站可有效访问的特性。
典型的分层模型是三层：应用层、服务层、数据层。关闭服务或者服务器宕机时对于各层产生的影响不同，高可用的解决方案差异也很大。
初此之外，还可通过一系列软件质量保证手段保证线上系统的可用性：网站发布、自动化测试、预发布验证、灰度发布等。

3.1 应用层：

应用层主要处理网站的业务逻辑，典型特点是无状态性，多个服务实例之间完全对等。可以通过负载均衡设备将一组服务器组成一个集群共同对外服务。
当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其在集群列表中移除，并将请求分发到其他可用的服务器上，从而实现高可用。

注：
①应用服务器集群的Session管理，一般是将应用服务器的状态分离——无状态的应用程序和有状态的session服务器（独立部署，统一管理session）。该种方式可用性高、伸缩性好、性能也不错（cookie管理：大小限制存储的信息量，传输cookie影响性能）。
②对于有状态的session服务器，一种比较简单的方法是利用分布式缓存、数据库等，在这些产品的基础上进行包装，使其符合Session的存储和访问要求。如果业务场景对Session管理比较高，则需开发专门的Session服务管理平台。

3.2服务层

与应用层类似，通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问（第五节详细介绍）。分布式服务调用框架会在应用层客户端程序中实现负载均衡，并通过注册中心对提供服务的服务器进行心跳检测，发现服务不可用，立即通知客户端程序修改服务访问列表，剔除不可用服务器。

除负载均衡外，还有以下几点高可用的服务策略：
①分级管理。
根据功能需要划分不同优先级，核心应用和服务使用更好的硬件——高优先级服务部署在不同物理机上。
同时也应注意有必要的隔离，避免故障连锁。
②超时设置。
服务器宕机、线程死锁等原因，可能导致服务端的调用失去响应，同时还占用应用程序资源，不利于及时将访问请求转移到正常服务器上。
设置超时时间，超时通讯框架抛出异常，失效转移。
③异步调用。
隔离：避免一个服务失败导致整个应用请求失败的情况。
④服务降级。
网站访问高峰期，为了保证核心功能正常使用，需要对服务降级。降级有两种手段：拒绝服务和关闭服务。
》拒绝服务：拒绝低优先级应用的调度。 ——避免“要死大家一起死”。
》关闭服务：关闭部分不重要的服务。如“双十一”关闭评价服务。
⑤幂等性设计。
应用调度失败后，会将请求发送给其他服务器。但是这个失败可能是因为网络故障没收到响应或其他原因导致的“失败”，这时候重复调用服务，可能会出现问题（如支付）。
服务重复调用无法避免，应用层也不关心服务是否真的失败，因此必须在服务层保证重复调用和调用一次产生的结果相同，即服务具有幂等性。

个人理解
除了集群失效转移之外，可用性还有如下思想提高可用性：分级管理、隔离、快速失败、幂等性。

3.3数据层

分析：由于数据存储服务器上保存的数据不同，当某台服务器宕机后，数据访问请求不能任意切换到集群中的其他机器上。
手段：数据备份和失效转移机制
1.数据备份：保证数据有多个副本，任意副本失效都不会导致数据永久丢失，从而实现数据完全的持久化。
数据备份包括数据热备和数据冷备。
》冷备：数据复制到存储介质上并物理存档保管
》热备：热备分为两种：异步热备和同步热备
①异步热备：多份数据本写入操作异步完成。应用程序收到数据服务系统的写操纵成功响应时，只写成了一份（主），存储系统会异步地写入其他副本（从）。
注：关系数据库的主从同步机制，写操作之访问主数据库，读操作只访问从数据库，实现了读写分离
②同步热备：多份数据副本的写入操作同时完成。存储服务器完全对等，无主从之分。一般等待所有存储服务器都返回操作成功的响应后，再通知应用程序写操作成功。
2.失效转移：保证当一个数据副本不可访问时，可以快速切换到访问数据的其他副本。
失效转移操作分为三个步骤：失效确认，访问转移，数据恢复
①失效确认。确认服务器是否宕机手段有两种：心跳检测和程序访问失败报告。
对于后者，程序访问失败后，有必要再进行心跳检测确认。毕竟失效转移代价太高，若误判代价太大。
②访问转移
对等，则转移到其他对等服务器上；不对等，需要重新计算路由选择存储服务器。
③数据恢复
服务器宕机后，数据存储的副本数目减少，必须将副本的数目恢复到系统设定的值。防止再有服务器宕机时，无法访问转移

高可用分布式存储设计思路：
1.瞬时故障：
失效确认。瞬时故障短暂时间内即可自行恢复，遇到后只需要多次重试请求，就可以重新连接到服务器。
2.临时故障：
发现故障不是瞬时故障，采用临时服务器进行写操作，故障修复了，将临时服务器写入的数据迁移到修复好的服务器中。
读操作，只选择正常状态下的服务器读数据。
3.永久故障：
读操作，只选择正常状态下的服务器读数据。
写操作，首先同时写入正常服务器和临时服务器；发觉故障为永久故障而非临时故障，则新数据同时写入正常服务器和代替故障服务器的新服务器，然后正常服务器的数据也要复制到新服务器中，同时，删除临时服务器写入的数据。

四、伸缩性

4.1概述

1.伸缩性分两类：①根据功能进行物理分离（不同的服务器部署不同的服务）实现伸缩。②单一功能通过集群实现伸缩（多台服务器部署相同的服务，提供相同的功能）

个人理解：
第二条，集群是实现伸缩性的手段不用多说。
第一条扩展还是伸缩？两者都是吧。
①联想原始网站是应用程序、数据库、文件等部署在同一台机器上，后来分离部署，获得跟高cpu，高大内存，是通过增加/减少设备数量来扩大/缩小服务器的处理能力，故而可以理解为伸缩性。
②而分割分布式部署，解耦同样是助于提高扩展性的。
第一条比较简单，所以伸缩性主要还是研究第二条。伸缩性可以简单理解为多台服务器提供相同的功能。  所以我认为“伸缩性>集群=多台服务器提供相同的功能/服务”。本节接下来的内容都是讨论第二条的。

2.集群伸缩性可分为①应用程序服务器集群伸缩性和②数据服务器集群伸缩性（缓存数据服务器集群+存储数据服务器集群）
3.集群对于数据状态管理的不同，技术实现也不同
①无状态：负载均衡算法定位列表中进行数据处理的服务器+借助负载均衡服务器实现将请求数据发送到对应的web服务器上
②有状态：在无状态基础上还要考虑状态变化。具体情况具体分析。

4.2负载均衡

1.负载均衡
》目标：负载均衡服务器作为请求分发装置，可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务分发请求，停止向已下线的服务器分发请求。
》过程：将用户请求按照某种规则分发到集群的不同服务器上。由于任何一台服务器处理结果都是相同的（无状态前提下），所以当某台服务器故障后，负载均衡服务器会将该服务器上的请求分发到其他服务器上代替处理。
》好处：实现网站的伸缩性，同时改善网站的可用性。
2.实现负载均衡的基础技术包括以下几种：
①HTTP重定向负载均衡—— HTTP重定向服务器作为负载均衡服务器
②DNS域名服务器负载均衡——DNS服务器处理域名解析请求的同时进行负载均衡处理

个人理解：
实际使用往往将域名解析作为第一级负载均衡手段，真实处理请求的web服务器由第一级处理的结果（提供负载均衡的内部服务器）再次负载均衡定位得到。
这么使用的原因是：当集群中某台服务器下线时，若采用多级域名解析作为负载均衡的手段，容易出现响应延迟（下线的服务器A可能被多级DNS缓存，及时修改了DNS的A记录，生效也需要一定时间）。故而只采用第一级DNS，然后再通过内部的负载均衡服务器处理。

③反向代理服务器负载均衡—— 和反向代理服务器功能集成在一起
注：由于Web服务器不直接对外提供访问，因此Web服务器不需要使用外部IP地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
④IP负载均衡 ——在网络层通过修改目标地址进行负载均衡

⑤数据链路层负载均衡——在数据链路层修改Mac地址进行负载均衡。

拓展阅读：负载均衡技术实现
https://www.cnblogs.com/yeyublog/p/6438373.html
https://blog.csdn.net/mengdonghui123456/article/details/53981976

4.3负载均衡算法

1.目标：根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址
2.负载均衡算法通常有
①轮询
②加权轮询
③随机
④最少连接
⑤源地址散列（hash）

4.4服务器集群伸缩性设计

1.应用程序服务器集群
应用服务器应该设计为无状态的（应用服务器不存储上下文信息。）
负载均衡+负载均衡算法
2.分布式缓存服务器集群
》分布式缓存之于集群的特性：分布式缓存服务器集群中不同服务器中缓存的数据各不相同，故而，缓存访问请求必须先找到缓存有需要数据的服务器，然后才能访问。而新上线的缓存服务器没有缓存任何数据，而已下线的缓存服务器还缓存着许多热点数据。
》主要目标：新加入缓存服务器后使得整个缓存服务器集群中已经缓存的数据尽可能还被访问到。
》问题分析解决：
①问题：分布式缓存扩容的时候，事情会变得很棘手。简单的路由算法可以使用余数Hash算法，扩容时，服务器规模越大，不能命中的概率越大。
②解决方案：虽然可以在网站访问少时扩容服务器集群、进行缓存预热，仍是治标不治本。必须改进路由算法，目前比较流行的是使用一致性hash算法。
》分布式缓存的一致性Hash算法
核心思想：
①节点构成环，降低影响（只影响了新节点加入位置周围两节点间的命中率）。然而在原始环上增加一个节点会打乱原始环中节点间缓存数据量/负载压力的比例。
②进一步改进：需要依靠增加虚拟层，每个节点虚拟化为多个节点分布在环中，一定程度上削弱增加节点带来的打乱原始负载/缓存数据量比例的影响。
注：一台服务器虚拟为多少个虚拟服务器节点合适呢？太多会影响性能，太少又会导致负载不平衡。一般来说，经验值是150

拓展阅读：
https://www.cnblogs.com/lpfuture/p/5796398.html 一致性哈希算法原理

3.数据存储服务器集群
》缓存集群之于数据存储服务器集群
缓存的目的是加快读取速度，减轻存储服务器压力，缓存丢失还可从数据库等存储服务器上获取。
故而，数据存储服务器集群对数据的持久型和可用性提出了更高的要求，缓存服务器集群伸缩性不能直接适用于数据库等存储服务器。
》重点任务：集群伸缩的同时，需要保证数据的可靠存储，任何情况下都保证数据的可用性和正确性
①关系数据库集群的伸缩性设计
基本的：数据库主从分离读写，主从复制，数据一致。
数据分库：不同业务的数据表部署在不用的数据库集群上，类似于业务分割。
数据分片：将一些很大的表单数据（如淘宝的商品数据库），进行分片，将一张表拆分开分别存储在多个数据库中。

	个人体会：
	以上内容进一步说明伸缩性=增加/减少服务器处理业务>增加/减少功能一致服务器处理业务.
	另外，“功能一致”这个词也要看层面，数据分库、数据分片虽然细分，功能不一致，但是整体功能都是存储数据又是一致。所以这些服务器都叫做“关系数据库”集群。故而集群这个词很模糊，怎样才是功能一致？
	业务功能一致还是不一致勿论，集群的判断重点看是否是一组服务器，因为“功能一致”细分可能不一致，大方面有可能是一致的。或许这就是“有状态”的特点吧。
	“分布式部署”这个词应该同时包含伸缩性和扩展性两个语义：①从大方面讲，分布式都是同一个功能（分布式缓存服务器，都是用来存缓存的），可以算这一组是集群。②细粒度来讲，分布式部署的是分层/分割得到的功能有别的各个模块，从这个角度来讲，是解耦，利于系统扩展。

以支持分片的分布式数据库产品Cobar为例，观察它如何实现伸缩，同时保证数据存储的正确性与可用性。

对比思考：
》与直接分片对比，使用cobar的好处？ cobar集群
Cobar 服务器可以看作是无状态的应用服务器，所以可以直接使用负载均衡手段实现集群伸缩。而 MySQL 服务器中存储着数据，所以我们要做数据迁移（把集群中原有的服务器中的数据迁移到新的服务器），才能保证扩容后数据一致负载均衡。

》与缓存数据库集群采取的伸缩性设计方法相比，该方法如何保证了数据存储的正确性和可用性？

可以利用一致性 Hash 算法进行数据迁移，尽量使得要迁移的数据最少。实践中，Cobar 服务器利用 MySQL 的数据同步功能进行数据迁移。迁移是以 Schema 为单位。

拓展阅读：
https://blog.csdn.net/hxpjava1/article/details/60468263 阿里开源Mysql分布式中间件：Cobar

②Nosql数据库集群的伸缩性设计
》为了应对大型网站遇到关系数据库难以克服的缺陷——糟糕的海量数据处理能力及僵硬的设计约束，NoSql被提出弥补关系数据库的不足。
》Nosql：非关系的、分布式的数据库设计模式。放弃了关系数据库的两大重要基础：结构化查询和事务一致性保证。更关注网站的高可用性和伸缩性。
》Apache Hbase应用最广泛的Nosql产品之一
拓展阅读：https://www.cnblogs.com/caiyisen/p/7424177.html HBase核心知识点总结

五、扩展性

伸缩性主要依靠将系统模块解耦、分布式部署，然后将各模块聚合的形式实现。模块分布式部署以后聚合方式主要有：消息队列和分布式服务。

5.1分布式消息队列

1.消息队列
①工作模式：消息队列利用发布——订阅模式工作。消息发送者发送信息，一个/多个消息接收者订阅消息。消息发送者在对消息进行处理并送到分布式消息队列后，消息接收者从分布式队列获取该消息后继续进行处理。
②特点：
消息发送者和消息接收者无直接耦合，消息发送者不需等待消息接收者处理完即可返回，有更好的响应延迟；
网站访问高峰时，消息可以暂存于消息队列，等待接收者根据其负载能力控制处理速度，减轻数据库等后端存储的压力。

2.分布式消息队列架构原理

过程
①消息生产者应用程序通过远程访问交界口将信息推送给消息队列服务器，消息队列服务器将消息写入本地内存后立即返回成功响应给生产者。
②消息队列服务器根据订阅列表查找订阅该消息的消费者应用程序，将队列中的消息按照FIFO原则，通过远程通信接口发送给消费者进程。

分析：
①伸缩性：
消息队列服务器上数据可看作被即时处理的，类似于无状态服务器。伸缩性设计只需将新服务器加入分布式消息队列集群，并通知生产者服务器更改消息队列服务器列表即可。
②可用性：
》为了避免消费者进程处理缓慢，造成消息队列服务器内存不足问题：如果内存已满，可写入到磁盘；消息推送模块处理完内存队列的消息后，将磁盘内容加载到内存队列继续处理。
》为了避免消息队列服务器宕机造成信息丢失：将消息成功发送到消息队列的信息存储在生产者服务器，等消息真正被消费者服务器处理后才删除信息；在消息队列服务器宕机后，生产者服务器会选择集群中其他服务器发布消息。

5 .2分布式服务打造可复用的业务平台

1.背景及解决思想
问题：巨无霸系统将会带来编译部署困难、代码分支管理困难、数据库连接耗尽等问题。
解决方式：通过拆分，将模块独立部署，降低系统耦合。拆分分为纵向拆分和横向拆分。
》纵向拆分：梳理业务，将一个大应用拆分为多个小应用，如果新增业务比较独立，那就将其设计部署为一个独立的Web应用系统。
》横向拆分：将复用的业务拆分开来，独立部署为分布式服务，新增业务只需调用这些分布式服务，不需要依赖具体的模块代码。
纵向拆分较简单，而横向拆分不但需要识别可复用的业务、设计服务接口、规范服务依赖关系，还需要完善的分布式服务管理框架。

2.分布式服务框架的架构原理
》分布式服务通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。
分布式服务框架一般需要支持负载均衡、失效转移、高效的远程通信、整合异构系统、对应用最少侵入等特性。
》阿里巴巴分布式开源框架Dubbo

①服务消费者程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较少侵入：应用程序只需要调用服务接口，服务框架根据配置自动调用本地或远程实现。
②服务框架服务器端：服务提供者启动后自动向服务注册中心注册自己提供的服务接口列表。
③服务框架客户端：服务框架客户端通过服务注册中心加载服务提供者列表，查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器（如果服务调用失败，客户端模块会自动从服务提供者列表中，选择一个可提供相同服务的另一台服务器重新请求服务，实现服务的自动失效转移）。
④Dubbo远程服务通信模块支持多种通信协议和数据序列化协议，使用NIO通信框架，具有较高的网络通信性能。

3.更进一步，利用开放平台建设网站生态圈
网站必须提供更多的增值服务才能赚钱，开放平台是内部和外部的接口，外部需要面对众多第三方开发者、对内需要面对网站内诸多业务服务。开放平台架构设计一般包括：
①OpenAPI、协议转换（提供给第三方，并将其输入转换为内部可识别的形式）；
②安全、审计（完成身份识别、权限监控、计费等功能）；
③路由、流程（将开放平台的访问路由到具体的内部服务，将原来离散的服务组织成一个隐藏服务细节上下文相关的新服务）。

5.3其他——可扩展数据结构

》问题：关系型数据库表结构带来数据结构僵硬，难以面对需求变更的挑战，尽管使用冗余字段应对仍不理想。
》解决方案：Nosql数据库使用列族设计就是一个解决方案，创建表的时候，只需要指定列族名字，具体字段可以在写入时再指定。通过这种方式，数据表可包含数百万字段，使得应用程序数据结构可以扩展。

六、安全

6.1网站应用攻击和防御

1.XSS攻击
XSS（跨站点脚本攻击），指黑客通过篡改网页注入恶意HTML脚本，在用户浏览网页时，控制浏览器进行恶意操作的一种攻击方式。攻击类型包括：反射型和持久型。
①反射型XSS攻击：攻击者诱使用户点击一个嵌入式恶意脚本链接，攻击者可以采用XSS攻击偷取用户cookie、密码等重要数据。

②持久型/存储型XSS攻击：黑客提交含有恶意脚本的请求，保存到被攻击Web站点的数据库中，用户浏览网页时，恶意脚本会被包含在正常页面中，达到攻击的目的。此种攻击经常使用在论坛、博客等Web应用中。

应对策略：
①消毒：XSS攻击一般都是通过在请求中嵌入恶意脚本达到攻击目的，这些脚本一般用户输入不会使用，如果进行过滤和消毒处理（即对html危险字符转义，如“>”转义为“&gt”），就可以防止大部分攻击。
②HttpOnly：因为浏览器禁止页面JavaScript访问带有HttpOnly属性的cookie。所以可以通过对该Cookie添加HttpOnly属性的方式，防止XSS攻击者窃取Cookie。

2.注入攻击
注入攻击主要有两种形式：SQL注入和OS注入攻击。
注入攻击是应用违背了“数据与代码分离原则”导致的结果。只需要牢记“数据与代码分离原则”，在“拼凑”发生的地方进行安全检查。就能避免此类问题。
防御方式：采用预编译手段进行参数绑定、消毒（通过正则表达式过滤请求数据中可能注入的SQL）。

3.其他攻击和漏洞
》CSRF攻击：跨站点请求伪造 。即利用跨站请求，在用户不知道的情况下，以用户身份伪造请求。 https://www.cnblogs.com/wangyuyu/p/3388169.html
防御手段主要是识别请求者身份：
①验证码（请求提交时，需要用户输入验证码）
②表单Token（在请求中增加随机数的方法组织攻击者获得请求参数）
③Referer check（Http请求头的referer域记录着请求拉远）
》漏洞：
①Error Code错误回显—— 异常堆栈信息直接输出到客户端浏览器。
②HTML注释——开发人员在PHP、JSP等服务器页面程序使用HTML注释语法进行注释，这些注释会显示在客户端浏览器。
③文件上传——上传某些可执行文件获得服务端命令执行能力，从而为所欲为。最有效防御方式是设置白名单，只允许上传可靠的文件类型。
④路径遍历——攻击者在请求的URL中使用相对路径，遍历系统未开放的目录和文件。防御方式：JS、CSS等资源文件部署在独立服务器上、使用独立域名；其他文件不使用静态URL访问；动态参数不包含文件路径信息。

6.2加密

为了保护网站敏感数据，需要对其进行加密处理。信息加密技术可分为三类：单项散列加密、对称加密、非对称加密。

1.单项散列加密。
》通过不同输入长度的信息进行散列计算，得到固定长度的输出。散列计算的过程是单向的，且输入的任何微小变化都会导致输出的完全不同。
》应用场景：密码加密保存。
》破解：通过彩虹表（人们常用密码和对应的密文关系表）等手段进行猜测式破解。
》为了加强单项散列计算安全性，还会给散列算法加点盐（加密的密钥）。常用的单项散列算法包括：MD5、SHA等。

2.对称加密。
》所谓对称加密是指加密和解密使用的密钥是同一个密钥（或者可以互相推算）。传统也是最常用的加密手段，适用于绝大多数加密的场合。
》应用场景：信息需要安全交换或存储的场合，如cookie加密、通信加密等。
》常用的加密算法有DES算法、RC算法等。

3.非对称加密。
》加密和解密的密钥不是同一个密钥，其中一个对外界公开（公钥），另一个只有所有者知道（私钥）。二者加密的信息只有对方才能解开。
》应用场景：信息安全传输、数字签名等场合。
》过程描述：
①信息发送者A通过公开渠道获得信息接受者B的公钥，对提交信息进行加密，然后通过非安全传输通道将密文发送给B，B得到密文后，用自己的私钥进行解密。即使密文信息在传输过程中遭到窃取，窃取者没有解密密钥也无法还原明文。
②数字签名过程则相反，签名者用自己的私钥对信息进行加密，然后发送给对方，接收方用签名者的公钥进行解密，获得原始明文信息，由于私钥只有签名者拥有，信息不可抵赖，具有签名的性质。
》常用算法有RSA算法等。
》如果有人偷换公钥为自己的公钥，冒充信息接受者与信息发送者（以下称用户）进行通信，怎样验证公钥的身份？——数字证书。
CA（证书中心）可以将（XX公钥及其所有者等）信息利用CA自身的私钥进行加密，用户可以通过CA提供的公钥进行解密，进而验证XX公钥的身份。

4.非对称加密和非对称加密混合使用
实际应用中，往往采取两种加密混合使用的方式：先使用非对称加密对对称密钥进行安全传输，然后使用对称加密技术进行信息加解密与交换。
而有时，对同一个数据两次使用非对称加密可以同时实现信息安全传输与数字签名的目的。

拓展阅读：
https://www.cnblogs.com/zfxJava/p/5295957.html 数字签名、数字证书、对称加密算法、非对称加密算法、单向加密（散列算法）

密钥本身是以明文方式保存的，从前述的几种加密技术中可以看出，信息的安全是靠密钥保证的，密钥安全性极为重要。
密钥安全管理方式：
①：把密钥和算法放在一个独立的服务器上，对外提供加密解密服务，供应用系统调用。专人维护、远程调用 ，成本较高，系统开销较大。
②：加解密算法放在应用系统中，密钥放在独立服务器中，实际存储时，密钥被分片保存在不同介质上。兼顾性能与安全。

6.3信息过滤

1.文本匹配——主要解决敏感词过滤问题。怎样查找敏感词？正则表达式匹配效率极差，一般采用Trie算法和构造多级Hash表进行文本匹配。
2.分类算法——识别垃圾信息、信息自动分类。比较实用的分类算法是贝叶斯分类算法。
3.黑名单——用于信息去重、垃圾邮件识别。可以通过Hash表实现黑名单，黑名单列表非常大时，可以用布隆过滤器（通过一个二级制列表和一组随机数映射函数实现）代替Hash表。

拓展阅读：
https://www.cnblogs.com/xujian2014/p/5614724.html 字典树(Trie树)实现与应用
https://www.jianshu.com/p/2104d11ee0a2 布隆过滤器的原理、使用场景和注意事项

6.4风险控制

电子商务存在账户盗用、卖家恶意占用库存、不良卖家恶意欺诈（如虚假发货）等风险。风控技术手段主要有规则引擎和统计模型
1.规则引擎：设置风控业务规则，通过使用指定的规则对比交易请求与历史数据评估风险，高风险则进行人工审核，否则正常交易。
2.统计模型：为了应对规则增加带来的规则冲突、难以维护问题，训练统计模型（分类算法或更复杂的及其学习算法只能统计）。实际使用：采集交易信息作为模型的输入，借助训练的模型，得到交易的风险分值。