架构师训练营第一期 - 第十一周学习总结

高可用架构分为两个部分：安全架构和高可用架构。

安全架构是在网络信息泄密及防御网络攻击在架构方面的设计考量。网络攻击常见的几种攻击手段及应对措施:

XSS攻击：恶意攻击者在web页面中会插入一些恶意的script代码。当用户登录web服务器浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。XSS 攻击防御手段是进行消毒处理，即对某些HTML 危险字符进行转义。

SQL注入攻击：通过构建特殊的输入作为参数传入Web应用程序，而这些输入都是符合SQL语法里的一些组合，在SQL解析时会被解析为符合语法的语句，在执行SQL语句时就会执行攻击者所要的操作。注入攻击的防御手段也是进行消毒处理，通过正则匹配过滤请求数据中可能注入的SQL文本。

CSRF跨站点请求伪造攻击：攻击者通过钓鱼网站等盗用了用户的身份信息，以用户的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以用户的名义发送邮件、发消息，盗取用户的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。CSRF 攻击防御手段是使用表单Token（在页面表单中增加一个随机数Token，每次请求的Token 都不相同）、签名验证（使用用户的设备指纹及其它用户数据通过加密生成签名）、验证码（片验证码、手机验证码）。

其他需要关注的攻击和漏洞

Error Code：也称作错误回显，许多Web 服务器默认是打开异常信息输出的，即服务器端未处理的异常堆栈信息会直接输出到客户端浏览器，这种方式虽然对程序调试和错误报告有好处，但同时也给黑客造成可乘之机。防御手段通过配置Web 服务器参数，跳转500页面。

HTML 注释：HTML 注释会显示在客户端浏览器，给黑客造成攻击便利。程序最终发布前需要进行代码review 或自动扫描，避免HTML 注释漏洞。

文件上传：一般网站都会有文件上传功能，设置头像、分享视频、上传附件等。如果上传的是可执行的程序，并通过该程序获得服务器端命令执行能力，那么攻击者几乎可以在服务器上为所欲为，并以此为跳板攻击集群环境的其他机器。最有效的防御手段是设置上传文件白名单，只允许上传可靠的文件类型。

路径遍历：攻击者在请求的URL 中使用相对路径，遍历系统未开放的目录和文件。防御方法主要是将JavaScript、CSS 等资源文件独立服务器、独立域名，其他文件不使用静态URL 访问，动态参数不包含文件路径信息。

上面的这些攻击或者进行防护的手段是互联网业界都要共同面对的，所以可以做一个通用的应用防火墙进行统一拦截。



道高一尺魔高一丈，总会有一些还不知道的攻击方式能攻击到你的系统中。除了采取被动防御的方式，还可以采取主动防御的方式，把敏感信息通过加密的方式存储起来，保护我们的信息，同时也提高了黑客攻击的门槛。

信息加密技术可分为三类：单项散列加密，对称加密，非对称加密。

单项散列加密：加密的过程是单向的，明文加密成密文后不能通过密文反算出明文。主要用于不需要知道明文的场景，典型的就是对用户密码进行加密处理。

对称加密：指加密和解密使用相同密钥的加密算法。

非对称加密:有两个公钥和私钥，公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。

必须保护好密钥，不能够泄露出去，因为算法是公开的。密钥需要使用专门的密钥安全管理和加解密服务系统来提供密钥安全的存储服务和加解密服务，应用程序调用服务接口对数据进行加解密就可以了。

反垃圾与防控，典型的场景反垃圾邮件。

1.选择一批邮件将正常邮件和垃圾邮件进行分类识别出来；

2.将分类好的邮件用分类算法进行训练得到一个分类模型，分类模型里包含了正常邮件和垃圾邮件的算法特征；

3.将待处理的新邮件分类识别模块进行处理；

4.分类识别模块调用训练好的分类模型进行识别，得出一些概率值，根据概率值判断是不是垃圾邮件；

这里的核心是分类算法及训练得到的模型。贝叶斯分类算法是一个典型的分类算法，公式如下：

垃圾邮件算法模型：包含茶叶这个词的邮件是垃圾邮件的特征值=（垃圾邮件包含茶叶这个词的概率*总邮件中垃圾邮件的概率）/茶叶这个词在所有特征值中出现的概率

交易安全是电子商务网站的底线。大型电商网站都配备有专门的风控团队进行风险控制，风控的手段也包括自动和人工两种方式。机器自动风控的技术手段主要有规则引擎和机器学习。规则引擎是当交易的某些指标满足一定条件的时候，就会被认为具有高风险的欺诈可能性。规则引擎虽然技术简单，但是随着规则的逐渐增加，出现规则冲突，难以维护等情况，而且规则越多，性能也越差。大型互联网应用更倾向于使用机器学习模型进行风控。



系统的可用性通常是以年为单位进行统计，以多少个9来做为度量的指标，大部分应用系统的指标是4个9即99.99%。

网站年度可用性指标＝（1－网站不可用时间/年度总时间）×１００％

根据上述公式可以算出99.99%的可用性指标要求下，系统不可用的时间为53分钟。

网站不可用时间（故障时间）＝故障修复时间点－故障发现（报告）时间点

高可用的绩效考核可以使用故障分管理进行考核：按故障产生的影响进行等级分类，不同的故障类别分配不同的权重，当出了事故的时候根据故障的等级分类以及权重算出对应的故障分，核算给具体的团队和人。



导致系统不可用的原因主要有：硬件故障、软件bug、架构不合理、设计有问题、系统发布、并发压力、网络攻击、外部灾害等。在进行架构设计、代码设计的过程中需要秉持“故障一定会发生”的理念，在设计时针对故障进行相关设计来提升系统的可用性，保障系统的稳定高可用。

保障系统稳定高可用的方案主要有：

解耦：系统的耦合度越高系统内部的关系越复杂，任何一个功能/模块的问题都可能影响其它模块，最后产生级联反应导致整个系统不可用。在架构设计上要采用解耦的原则和方法：高内聚、低耦合的组件设计原则、面向对象基本设计原则、面向对象设计模式、领域驱动设计建模，帮助降低模块代码的耦合度，代码的低耦合有利于提高系统的可用性。

隔离：通过将解耦以后的业务模块、子系统在物理上进一步进行隔离，即使是某个系统内部出现问题，这个问题在物理上也不会扩散到其它的子系统里从而提高了系统可用性。先通过在系统架构上的隔离设计，采用业务子系统隔离、微服务与中台架构、生产者消费者隔离等等这些架构进行逻辑上的隔离，再将架构设计上隔离出来的子系统或服务部署到不同的虚拟机、容器中进行物理上的隔离，从而来提升系统的可用性。

异步：可以采用多线程编程、反应式编程、异步通信网络编程进行代码解耦，一个线程的问题不会影响到其它线程的同时不会因为网络阻塞引起线程阻塞导致资源耗尽；还可以采用事件驱动异步架构在架构上解耦，这本质上还是利用消息队列来实现消费者生产者的隔离。

备份和失效转移：采用集群设计将应用服务进行多份部署，部署到多台服务器上，通过负载均衡服务器将请求分发到各服务器，当监控有服务器宕机时，由负载均衡服务器进行失效转移将对该服务器的请求转发到其它好的服务器上；将数据库做主从复制进行读写分离，一台服务器故障另一台还能提供读或写的服务；将数据库做主主复制，当提供服务的主服务器故障时，通过zookeeper选主进行失效转移，由另一台服务器提供服务，应用程序通过zookeeper访问主服务器。这种分布式的处理不仅提高了系统的性能同时也提高了系统的可用性。

幂等：应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。服务重复调用有时候是无法避免的，必须保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态。在分布式系统中通常使用事务补偿的机制实现事务的一致性，如果某个事务执行到某一步失败，则将这个事务这一步之前所做的操作使用日志记录进行逆操作回滚掉。

重试：远程服务可能会由于线程阻塞、垃圾回收或者网络抖动，而无法及时返还响应，调用者可以通过重试的方式修复单次调用的故障。重试需要特别关注的一点：上游调用者超时时间要大于下游调用者超时时间之和。

熔断：当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。断路器三种状态：关闭，打开，半开。

限流：在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是比整个系统崩溃所有的用户都不可用要好。限流的几种算法：计数器算法（固定窗口，滑动窗口）、令牌桶算法、漏桶算法。

降级：有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，在系统高并发的时候关闭这些非核心功能。比如说像淘宝双11 的时候，当天可能整天系统都处于一种极限的高并发访问压力之下，这时候就可以将确认收货、评价、历史订单查询这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。

异地多活：如果数据中心所在城市遭遇了地震，机房遭遇了火灾或者停电时，不管我们的设计和系统多么的高可用，系统依然是不可用的。为了解决这个问题，同时也为了提高系统的处理能力和改善用户体验，很多大型互联网应用都采用了异地多活的多机房架构策略，将数据中心分布在多个不同地点的机房里，这些机房都可以对外提供完整服务，用户可以连接任何一个机房进行访问，即使某一个机房不可使用，系统也还可以在另外的机房为用户提供服务，依然保持可用。异地多活的难点是数据一致。

系统的高可用并不是使用某一种方案就能一蹴而就的，不同的场景需要不同的方案，很多的时候需要同时使用几种方案。在进行系统高可用的设计实现时，应该根据系统发展阶段、业务特点及业务量进行分析评估，选择多种方案组合形成满足自己业务需求的高可用方案。



高可用的运维是说在系统的发布运维环节可能会导致系统故障或降低系统可用性的一些问题如何应对的方法。系统发布其实就是一次系统停机，新的代码要发布上线需要先Kill掉老系统的进程，就会导致系统访问不可用。因此需要采用负载均衡失效转移的手段来避免服务的不可用。

代码在发布到线上服务器之前需要进行严格的测试。即使每次发布的新功能都是在原有系统功能上的小幅增加，但是为了保证系统没有引入未预料的BUG，网站测试还是需要对整个网站功能进行全面的回归测试。此外还需要测试各种浏览器的兼容性，在发布频繁的网站应用中，如果使用人工来进行，成本和时间都难以承受。因此需要采用自动化测试技术，使用自动测试工具或脚本完成测试。

在系统早期，由于系统功能还不完善、功能在不断增加，代码变化很快，这时候如果使用自动化测试就需要不断地去修改自动化测试脚本，投入的成本比手工测试更大。随着时间的推移，系统大部分功能都稳定了，新的功能变化只局限在一小部分代码上，这时使用自动化测试的成本就会比手工测试成本低。

自动化部署是说开发工程师开发完代码后，直接提交代码到版本控制工具（git），自动会触发自动化的测试，测试完成没有发现bug所有的功能正常自动会触发发布功能自动就发布了。也就是代码发布即系统发布。通过这种方式去管理全部的发布过程，提高了效率的同时降低了人工参与引起的各种问题。

自动化的持续部署可以分为三步：

持续集成：允许工程师随时向公共分支提交代码，并立即进行自动化测试。

持续交付：除了跑单元测试及软件打包，持续交付机制会将软件部署到各种测试环境中

持续部署：代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。

对于大型互联网系统，核心应用系统和公用业务模块涉及许多团队和工程师，需要对相同的代码库进行共同开发和维护，而这些团队对同一个应用的开发维护，其开发周期和发布时间点各不相同。因此需要使用版本控制来进行管理，主要有两种方式：主干开发分支发布和分支开发主干发布，通常都是采用第二种方式。

由于网站的版本发布频繁，整个发布过程需要许多团队合作，发布前多个代码分支合并回，主干可能会发生冲突（conflict），预发布验证也有风险，只要有一个地方处理失败就会造成发布失败而开始重新发布。这就使得整个版本发布工作量巨大人工成本很高，因此而产生了自动化发布工具来进行自动的发布工作。

应用发布完成功后，仍然可能会发现因为软件问题而引入的故障，这时候就需要做发布回滚。为了应付这种局面，大型网站会使用灰度发布模式，将集群服务器分成若干部分，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器，持续几天的时间才把整个集群全部发布完毕，期间如果发现问题，就只需要回滚已发布的一部分服务器即可。

系统应用发布上线之后并不是就高枕无忧了，因为我们并不知道系统运行过程中什么时候会发生我们意料之外的故障。所以还需要对系统运行时进行监控，掌握系统运行状态，对异常状态进行告警处理以便及时采取措施减少故障影响。对系统进行监控就必须要采集相应的监控数据，这些数据主要包括：用户行为日志，业务运行数据和系统性能数据等。监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等，还可以根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。