《架构基础 从需求到架构》读书

《架构基础 从需求到架构》读书

《架构基础 从需求到架构》这本书我去年读过前两章，当时我的感受是醍醐灌顶，最近我用了一周的时间把整本书读了一遍，依然收获颇多。强烈推荐小伙伴们都看看，相信会对你有帮助。这里我再梳理一些技术点，加深印象。

  1. 每一个架构师都是一个笨鸟先飞的程序员

  2. 架构师的重要之处在于将抽象的东西具体化，让复杂的事情简单化，让众多部门人员清楚自己的职责，有序的实现各自部分的系统功能

  3. 架构师是需求与开发之间的桥梁，它并不是一个纯技术岗位

  4. 一名资深架构师需要保持终身学习的心态

  5. 程序员如何提高自己的架构能力：反复认真的看系统原型，反复认真的看需求文档，反复认真的看设计文档，扩大自己的视角，养成刨根问底的习惯，练习文档写作能力，抓住每一个验证自己能力的机会，锻炼总结能力

  6. 架构师的12项必备技能：深入掌握一门面向对象的编程语言，熟练掌握各种设计模式，熟练掌握一种关系型数据库，能够熟练绘制各种UML图，至少掌握一种缓存性数据库，至少掌握一种文档性数据库，至少掌握一种消息中间件，对于线程池连接池对象池有深入的理解和掌握，对于各种数据结构和算法具有较为全面的掌握，对于并发编程具有深入的理解，掌握一种容器化技术，熟悉Linux服务器的使用

  7. 解决问题的思想才更加重要，尽早规则自己的职业生涯

  8. 高可用模式的核心思想是 冗余，容错，故障转移和系统监控

  9. Ngnix + Keepalive双机主备方案里，提到虚拟IP技术 VIP

  10. Ngnix 不够用后，可使用LVS或HAProxy + Ngnix做二级负载， 再不够用可以再加一层硬负载F5

  11. DNS服务 可以针对不同的地区、运营商绑定不同的IP地址，这样全国各地的用户进行访问时可以尽量将用户的请求解析到距离最近的服务器

  12. MongoDB高可用架构 的 副本集模式里 提到 选举算法， 集群各节点通过心跳机制， 冲裁节点只负责投票不存业务数据。 分片模式里分片算法：Hash,Range

  13. Redis不能完全替代关系型数据库，首先Redis基于内存存储和查询，虽然速度快，但是内存资源有限，无法像磁盘一样存储海量数据，其次Redis使用Key=Value形式存储，无法表达复杂的数据关系。

  14. Redis持久化 RDB模式里，主进程Fork一个子进程专门用于持久化,RDB模式缺点是造成数据丢失(定时引起)

  15. RDB持久化AOF模式里，日志回访模式恢复数据，AOF文件写入三种策略：always no everysec.

  16. Redis 主从模式里 如何将数据从主节点高效准确的复杂到从节点，主要分为 全量同步（fork rdb），增量同步(aof)，部分同步(偏移量 aof)

  17. Redis 哨兵模式，推荐至少采用3哨兵+3节点的结构部署。故障转移流程：

    1）. 哨兵A探测到主节点不通，标记为主观下线。但是A不一定准确， A 告诉 B C，然他们看看是不是真的

    2）.如果超过半数 都连不上主节点，就认为主节点已不可用，标记为客观下线

    3） A B C成立仲裁委员会 投票负责人， 负责人带领大家再选出一个主节点。

  18. Redis集群模式 使用哈希槽hashslot方式实现数据分片存储

  19. Kafka高可用 要借助于Zookeeper， 通过分区副本保证分区的高可用。 假如分为三个主题，每个主题里有3个区，每个主题里都有一份完整的数据，每个主题里又只有1/3的Leader部分， 这样保证即便一个区故障了，可以从其他主题复制数据。

  20. 关系型数据库的读写分离架构，主库一般只用于写， 从库用于读。 对实时性要求较高的业务也可以强制从主库读。 主从从架构 ，一主多从架构。

  21. 关系型数据库数据同步策略：异步复制（不等从库），全同步复制（等所有从库），半同步复制（等至少一个从库）。

  22. 高并发访问限流的目的是 保证系统的可用性，需要限流的场景有：系统资源有限，承载能力有限，大量并发访问导致系统性能下降甚至宕机，避免引起雪崩问题，系统某些接口遭受攻击导致整个系统无法访问。 客户端限流主要4种手段：纯前端验证码，禁用按钮，调用限制，假排队

  23. 漏桶算法 和 令牌桶算法的区别：漏桶无法处理突发请求，只能固定速度处理。 令牌桶 只有通中有足够的令牌 就可以，不是固定速度流程，适用性略好。

  24. 高伸缩性主要是指服务的水平扩展能力。水平拓展需要借助负载均衡技术，最好提供无状态服务。 无状态与有状态是相互对应的，主要看用户的多次请求是否存在上下文关系和依赖关系。

  25. 有状态服务改为无状态服务主要有两种方案：数据同步和数据共享。

  26. GFS（Google File System）设计目标主要是针对大文件存储，读多写少的场景，支持弹性伸缩。FastDFS 更适合存储占用空间小但数量巨大的碎文件。

  27. 高并发的主要策略有多级缓存策略，异步化策略和读写分离策略。

  28. 静态资源可以直接使用Ngnix的缓存功能，加快访问速度。

  29. 使用中间件缓存需要注意3种问题：缓存穿透（非法攻击 不存在的ID），缓存击穿（单一热点缓存到期），缓存雪崩（大量缓存同时到期）

  30. 同步异步阻塞非阻塞 场景区分，假如我们用洗衣机洗衣服，将所有的衣服 水 洗衣液都准备好

    1）同步阻塞， 启动开关后，洗衣机开始洗衣服，我们就站在洗衣机旁边守着，不断的去看洗完了吗

    2）同步非阻塞：启动开关后，我们就去做别的事情了，但是隔一段时间来看一下是否洗完了

    3）异步阻塞：启动开关后，我们就站在旁边守着，但是不再去看是否洗完了，而是洗衣机洗完后会自动播放音乐，通知我们洗完了

    4）异步非阻塞：启动开关后，我们就去做别的事了，等洗衣机洗完后会自动播放音乐，通知我们洗完了

  31. 数据脱敏必须从后端服务脱敏，不能采用前端JS脱敏

  32. SOA ESB最大的问题是让原本去中心化的系统变为了中性化的系统，ESB故障会导致整个系统不可用

  33. 微服务架构的缺点：拆分粒度难以界定，增加了运维难度，交易流程复杂，网络延迟增加

  34. 微服务架构的优点：分布式去中心化，服务伸缩性好，服务自治能力，服务内聚更高耦合更低，敏捷开发，异构开发，对硬件要求降低

  35. 注册中心的原理：

    1）注册中心是一个独立部署的微服务，专门负责服务注册与发现。将新启动的服务节点元数据保存到注册表中，将停止和异常的服务从注册表中剔除

    2）当订单服务 库存服务启动时，将自己的元数据信息发给注册中心，注册中心将数据保存到服务注册表中

    3）当订单服务请求服务时，先从注册中心获取注册表信息，查询到库存服务的ip地址端口， 然后订单服务会直接使用此ip去访问库存服务

    思考 每次请求都去注册中心问，性能不会降低吗？ 每个微服务都会在本地保存一份注册表副本，同时与注册中心保持同步关系。

  36. 微服务熔断机制，当触发熔断后 可以直接返回一个预制好的应答内容，从而保证整个交易链路可用。 微服务断路器 半开启状态后，会再有少量的请求尝试，如果服务正常，断路器变为关闭状态。

  37. 配置中心的3点好处：集中管理， 配置安全，动态调整

  38. 微服务改造的六大原则： 不要为了使用微服务而使用，不要妄想完美架构要用进化的眼光看架构，微服务拆分没有绝对的标准，不要忽略非功能性设计，环境网络隔离权限隔离，重视容器化持续集成和部署

  39. 多类型账号密码登录设计中，客户端匹配设计，由客户端根据正则表达式匹配 账号，邮箱， 手机

  40. 手机验证码登录设计中注意 验证码 手机号 TOKEN三个都要匹配。

  41. 手机号一键登录设计中设计 运营商认证SDK， 运营商认证服务器，涉及 掩码请求，TOKEN请求， 手机号请求

  42. 微信扫描登录 OAuth2.0协议

  43. 自己设计用户扫码登录设计，二维码供应商，App,App后端服务， 网站系统服务。

  44. 在一些系统升级之前会将用户主动踢出，并且不允许登录，保证系统发布过程中不被访问

  45. App主动踢出设计：个推服务 ； 被动踢出：等App访问后端时判断。

  46. 密码安全检查设计：检查库， 历史密码库

  47. 密码加密算法： MD5（MD5(原始密码) + salt） ,salt变 但有规则。

  48. 邮箱找回密码设计时，邮箱发送的url里包含token和加密邮箱， 用这俩绑定业务。

  49. RBAC模型演进：用户组模型，使用用经常要将多个角色授权给一类用户的情况

  50. 微服务里Token的延时与刷新（换值）

  51. 利用登录日志 分析 安全建模，单独组建 安全中心

  52. 菜单操作日志 的必要性：对追查问题意义很大，能够准确的还原当时的用户操作状态。 同时经常操作的菜单 是性能优化 提升体验的重点。 异步批量上报。

  53. 短信 防攻击设计，先探出验证码窗口，立即禁用按钮，倒计时。 验证码后端返回图片，不能前端生成。

  54. 防御重放攻击的方式：请求限流，黑名单（IP），利用交易流水号，验证时间戳，请求序号。

  55. 参数扫描攻击： 假如主键是 有顺序的数字，对外暴露后很可能被人利用，需要形成新编码，比如用MD5（ID+时间戳）

  56. 防篡改攻击： 交互加密AOP， 签名验证

  57. 站内信列表拉取设计： 短轮询（定时）， 长轮询（更适合聊天室）

  58. 站内信数据表设计 一个点： 一般是设计 消息表，用户消息关联表，这里注意 不一定 发送消息时就往用户消息关联表里插入数据。 假如消息是 发给全站用户，用户登录后可以只查消息表。 等真正读消息后写入关联表，减少数据存储。

  59. App消息推送设计里： IOS独立生态， Andorid各大手机商自己独立的服务。 App消息还分为 通知消息 和 透传消息（触发app的监听）

  60. 被动扫描监控设计： 定时任务监控， 集中配置定义规则和SQL脚本

  61. 海量数据处理的核心思想是 分片处理， 单线程变多线程， 另外一个思想是实时计算（时间跨度大）

  62. 参数项配置设计中 懒加载方式，只有使用时才加载。 假如更新配置时，可以利用消息队列 清除内存缓存

  63. 第十三章里 有多个设计实战，可以参考模式写论文，图文并茂，了解套路。

posted @ 2024-04-01 00:13  changlong2022  阅读(76)  评论(0)  编辑  收藏  举报