架构师训练营第十一周总结

架构师训练营第十一周总结



组件设计原则



组件最初用于把一堆常用的方法集中在一起，也就是方法的复用。

架构师职责在于把复杂度高的系统设计成一个个模块，每个模块复杂度很低，处理好各个模块之间的关系，降低整体的复杂度。



组件内聚原则 -- 目的在于讨论哪些类应该聚集在同一个组件中，使其既能提供相对完整的功能，又不至于太庞大



1、复用发布等同原则

软件复用的最小粒度等同于其发布的最小粒度。

-- 可供复用的软件产品包含了10种，其中除源代码外，还包括体系结构、需求模型和规约、各种设计、用户界面、数据、测试用例、用户文档、技术文档、项目计划和成本估计等。组件有小到大，可以包括方法函数，用户注册/登录功能，用户管理组件。

组件发布后，别人可以依赖组件，复用组件。

组件设计的粒度有多大，由业务场景决定。如果用户登录和注册是分别复用的，则登录和注册功能分开。如果是使用用户管理组件，则登录和注册会作为一个组件被使用。

业务上的变更会经常导致主版本号升级



2、共同封闭原则 --把相互关联性比较强的类放在一个组件中，即对系统不同功能升级的时候，对不同组件的修改量不同，目的是保证可维护性，修改量比较集中，缩小修改对其他组件带来的影响。

单一原则是面向对象的。

3、共同复用原则 --相互依赖的类，应该放在同一个组件中。

接口隔离原则 -- 不能强迫用户依赖不需要的东西

共同复用和共同封闭相互矛盾，需要思考判断哪个更重要一点。



组件耦合原则 -- 说明组件之间的调用依赖关系怎么设计

1、无循环依赖原则 -- 各个组件之间的依赖不能循环形成闭环。



避免循环依赖，必须做到单项依赖，组件之间的功能不能互相调用，有边界，架构文档要写清楚依赖和层次关系；否则系统必死无疑。



课程三部分：架构方法（架构文档很重要哦），程序设计，架构设计



2、稳定依赖原则 -- 组件a,b,c...依赖组件A，则组件A一定不能经常变化，一定是稳定的。而如果a,b,c...经常变化，则其是不稳定的，其一定要依赖于比自己稳定的组件，不然当A发生过多变化时，a,b,c......也会受到连锁反应



3、稳定抽象原则 -- 抽象描述的是接口和规范（稳定），不是具体实现（不稳定）

给组件设计一个接口类，封装在专门的组件中。这样别人就依赖接口组件（稳定），而不是依赖组件实现。



对稳定性不同的团队设计不同的组件



架构师核心三个维度：技术，业务，团队

自己思考关系，哪个对自己的架构设计比较重要，不要被合作团队或环境影响。



组件和模块区别

组件一般是物理的，独立发布的东西。

模块有时不是物理上的，是逻辑上的。



组件的依赖关系 -- 通过文档保证，系统的架构层次图，不同层次不能反向依赖



一个系统可以有很多个组件，把系统切分成若干个组件，让团队开发。



安全架构



XXS攻击 -- 跨站点脚本攻击，通过服务器攻击用户

防御方法：用户不能发脚本给服务器





sql注入攻击  -- 直接攻击服务器



防御：现今主流浏览器都支持过滤反射型了

SQL注入要用预处理Statement，但以前有人用存储过程，在那里拼接sql，这种用预处理也没办法了

方法：建立DMZ隔离区

CSRF最简单的防攻击办法，就是检查Referer，必须是来自可信任的域名。



错误回显：要显示给用户专门的页面，而不是代码错误。







CSRF攻击  -- 跨站点请求伪造



token防不了爬虫

验证码用于检验是人的请求还是机器的请求，用户可以知道是否是被利用了。



安全功能：正则表达式，网关，应用程序的过滤器



安全策略：web攻击，信息安全 参考modsecurity



信息加密及秘钥管理

加密：单项散列加密，对称加密，非对称加密

秘钥管理 ：认证，保证多人持有秘钥的不同部分



反垃圾邮件  -- 训练关键字（特征）



布隆过滤器黑名单



电子商务风险控制、

规则引擎

机器学习



高可用的度量

可用性指标：（1-年度不可用时间/年度时间）*100%

业界常用多少个9来衡量网站的可用性，如qq是99.99%



故障处理后一般是“甩锅”大会，然后诞生一个“背锅侠”。



引起故障的原因

硬件故障、软件故障（bug）、系统发布（版本控制，数据库和代码管理，服务器配置等）、并发压力（高并发压力过大）、网络攻击、外部灾害



高可用架构

解耦 -- 大多数公司不会像淘宝一样出现高并发现象，编程为主要优化对象

高内聚、低耦合的组件设计原则 -- 发布阶段出现问题概率高，依赖关系要清晰

面向对象的基本设计原则

面向对象设计模式

领域驱动设计建模



隔离-- 使得故障不会扩散

业务和子系统隔离   

微服务与中台架构

生产者和消费者隔离

虚拟机与容器隔离



异步 -- 同步导致一个失效，多个连锁失效

多线程编程

反应式编程

异步通信网络编程

事件驱动异步架构



备份 -- 当应用只部署在一个服务器上，服务器发生故障，则该应用不可使用

集群设计

数据库复制，CAP原理



失效转移 -- 检测到用户实

数据库主主失效转移

负载均衡失效转移



幂等



事务补偿



重试 -- 远程服务发生超时，保证重新服务再次重试可以修复单词调用的故障



熔断 -- 当服务器服务延迟和失败调用增加时，采用断路器熔断处理



限流 -- 在高并发情况下，设定好数值，丢弃一部分用户请求，保证大部分用户请求得到响应



自适应限流 -- 检测高并发情况，根据自身负载进行自适应限流



降级 -- -- 在高并发情况下关闭一些不重要的服务



异地多活 --在多个地方部署机房



高可用系统运维

发布

自动化测试 -- web功能测试，兼容性测试，采用WEB自动化测试工具或脚本完成测试

手工测试和自动化测试，业务前期可以用手工测试，后期复杂度增加采用自动化测试



自动化部署



持续部署流程



预发布验证 --把系统部署在生产环境的一台服务器上，但只能让测试人员登录，用户无法登录，测试人员在生产环境测试



代码版本控制 -- 主干发布，分支开发；分支发布，主干开发



自动化发布



灰度发布 -- 把服务器群分成几部分，先一个部分发布，无误再另一个部分发布，无误再下一个部分发布，如此类推，直到全部发布完



网站监控运营

监控数据采集

用户日志行为收集

服务器性能检测

业务运行数据报告

监控管理