Architecture Phase1 Week11:Summarize

主要讲解了安全架构及高可用架构。

安全架构

攻防手段得介绍。XSS攻击，SQL注入攻击，CSRF攻击，其他需要关注的攻击和漏洞。针对这些进行对应得防御。Web应用防火墙，网站安全漏洞扫描。

加密解密得手段，信息加密技术及密钥安全管理，单向散列加密，对称加密，非对称加密。

反垃圾和风控，贝叶斯分类算法，布隆过滤器黑名单。用于控制邮件列表过滤

电子商务风险控制

电子商务具有多种形式，B2B，B2C，C2C每种交易的场景都不相同，风险也各有特点，大致可分为以下几种：

账户风险：包括账户被黑客盗用，恶意注册账号等几种情形。

买家风险：买家恶意下单占用库存进行不正当竞争；黄牛利用促销抢购低价商品；此外还有良品拒收，欺诈退款以及常见于B2B交易的虚假询盘等。

卖家风险：不良卖家进行恶意欺诈的行为，例如货不对板，虚假发货，炒作信用等，此外还有发布违禁商品、侵权产品等。

交易风险：信用卡盗刷，支付欺诈，洗钱套现等

大型电商网站都配备有专门的风控团队进行风险控制，风控的手段也包括自动和人工两种方式。机器自动识别为高风险的交易和信息会发送给风控审核人员进行人工审核，机器自动风控的技术和方法也不断通过人工发现的新风险类型进行逐步完善。机器自动风控的技术手段主要有规则引擎和机器学习

规则引擎当交易的某些指标满足一定条件的时候，就会被认为具有高风险的欺诈可能性。比如：•用户来自欺诈高发地区；

交易金额超过某个数值；

和上次登录的地址距离差距很大；

用户登录地与收货地不符；

用户第一次交易；

大型网站在运营过程中，结合业界的最新发现，会总结出数以千计的此类高风险交易规则。一种方案是在业务逻辑中通过编程方式使用if...else...代码实现这些规则，可以想见，这些代码会非常庞大，而且由于运营过程中不断发现新的交易风险类型，需要不断调整规则，代码也需要不断修改



机器学习，规则引擎虽然技术简单，但是随着规则的逐渐增加，出现规则冲突，难以维护等情况，而且规则越多，性能也越差。大型互联网应用更倾向于使用机器学习模型进行风控



高可用系统得度量

可用性指标

网站年度可用性指标＝（1－网站不可用时间/年度总时间）×１００％网站不可用时间（故障时间）＝故障修复时间点－故障发现（报告）时间点



故障分管理

故障处理流程及考核

引起故障的原因1.硬件故障2.软件bug3.系统发布4.并发压力5.网络攻击6.外部灾害



高可用系统架构

解耦

高内聚、低耦合的组件设计原则

面向对象基本设计原则

面向对象设计模式

领域驱动设计建模

隔离

业务与子系统隔离

微服务与中台架构

生产者消费者隔离

虚拟机与容器隔离

异步

多线程编程

反应式编程

异步通信网络编程

事件驱动异步架构



备份

集群设计

数据库复制

CAP原理

Failover（失效转移）

数据库主主失效转移

负载均衡失效转移

如何确认失效，需要转移？

设计无状态的服务

幂等

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但是因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用，如果这个服务是一个转账操作，就会产生严重后果。服务重复调用有时候是无法避免的，必须保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。有些服务天然具有幂等性，比如将用户性别设置为男性，不管设置多少次，结果都一样。但是对于交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才继续执行

事务补偿

传统事务的ACID

原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）分布式事务的BASE

基本可用（Basic Availability ）、软状态（Soft-state）、最终一致性（Eventual consistency）

事务补偿：通过执行业务逻辑逆操作，使事务回滚到事务前状态



重试

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

熔断

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

断路器三种状态：关闭，打开，半开

限流

在高并发场景下，如果系统的访问量超过了系统的承受能力，可以通过限流对系统进行保护。限流是指对进入系统的用户请求进行流量限制，如果访问量超过了系统的最大处理能力，就会丢弃一部分的用户请求，保证整个系统可用，保证大部分用户是可以访问系统的。这样虽然有一部分用户的请求被丢弃，产生了部分不可用，但还是好过整个系统崩溃，所有的用户都不可用要好。

限流的几种算法

计数器算法（固定窗口，滑动窗口）

令牌桶算法

漏桶算法





自适应限流

没有提前的人工评估，便没有提前的评估过时与人的评估疏漏/错误!

实时自动评估QPS

业务流量的不确定性与技术方案的自适应性天生一对!

降级

有一些系统功能是非核心的，但是它也给系统产生了非常大的压力，比如说在电商系统中有确认收货这个功能，即便我们不去确认收货，系统也会超时自动确认收货。但实际上确认收货这个操作是一个非常重的操作，因为它会对数据库产生很大的压力：它要进行更改订单状态，完成支付确认，并进行评价等一系列操作。如果在系统高并发的时候去完成这些操作，那么会对系统雪上加霜，使系统的处理能力更加恶化。解决办法就是在系统高并发的时候，比如说像淘宝双11 的时候，当天可能整天系统都处于一种极限的高并发访问压力之下，这时候就可以将确认收货、评价这些非核心的功能关闭，将宝贵的系统资源留下来，给正在购物的人，让他们去完成交易。



异地多活

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



高可用系统的运维



发布

网站需要保证7×24高可用运行，同时网站又需要不断的发布新功能吸引用户以保证在激烈的市场竞争中获得成功。许多大型网站每周都需要发布一到两次，而中小型网站则更加频繁，一些处于快速发展期的网站甚至每天发布十几次。不管发布的新功能是修改了一个按钮的布局还是增加一个核心交易功能，都需要在服务器上关闭原有的应用，然后重新部署启动新的应用，整个过程还要求不影响用户的使用。这相当于是要求给飞行中的飞机换个引擎，既不能让飞机有剧烈的晃动，也不能让飞机降落，更不能让飞机坠毁。既然网站的发布过程事实上和服务器宕机效果相当，那么就可以用服务器宕机的高可用方案来应对网站的发布。所以设计一个网站的高可用架构的时候，需要考虑的服务器宕机概率不是物理上的每年一两次，而是事实上的每周一两次。也许你认为这个应用不重要，重启也非常快，用户可以忍受每年一到两次的宕机故障，因而不需要复杂的高可用设计。事实上，由于应用的不断发布，用户需要面对的是每周一到两次的宕机故障。用户哭了。

自动化测试

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



自动化部署



持续部署三步走

持续集成

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

持续交付

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

持续部署

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



预发布验证

预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上，外部用户无法访问



关于发布，各团队依照自己得特性进行主干发布，或分支发布，自动化发布等。发布一定要管理好版本。



网站运行监控

“不允许没有监控的系统上线”，这是许多网站架构师在做项目上线评审的时候常说的一句话。网站运行监控对于网站运维和架构设计优化至关重要，没有监控的网站，犹如盲人骑瞎马，夜半临深渊而不知。生死未卜，提高可用性、减少故障率就更无从做起了。

监控数据采集

广义上的网站监控涵盖所有非直接业务行为的数据采集与管理，包括供数据分析师和产品设计师使用的网站用户行为日志，业务运行数据和系统性能数据等。

监控系统架构

针对故障分析，从物理故障到Redis缓存雪崩等都有，需要根据项目自身可能存在得问题进行排查。