《从零开始学架构》读书

《从零开始学架构》读书

由于软考变革，一些计划下半年读的书开始提前读，《从零开始学架构》这本书大概读了十天，合上书后反想确实是有些收获，再梳理下加深印象

  1. architecture refers to the fundamental structures of a software system, the discipline of creating such structures, and the doucumentation of these structures. 软件架构是指软件系统的 基础结构，创造这些基础结构的准则，以及对这些结构的描述

  2. As the size of software systems increases, the algorithms and data structures of the computation no longer constiture the major design problems. when systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems. 随着软件系统规模的整洁，计算相关的算法和数据结构不再构成主要的设计问题，当系统由多部分组成时，整个系统的组织，也是所说的软件架构，导致了一系列新的设计问题

  3. 架构设计的主要目的是为了解决复杂度带来的问题。

  4. 高性能：单台计算机（多进程，多线程，进程间通信，多线程并发等），多台计算机集群（任务分配，连接管理，分配算法， 任务分解）

  5. 高可用是指系统无中断地执行其功能的能力，高可用方案本质都是通过冗余来实现

  6. 高可用状态决策： 独裁式（缺点是如果决策者本身故障，系统无法实现准确的状态决策）； 协商式；民主式（闹裂问题通过投票点数必须超过系统总节点数的一半解决）

  7. 扩展性：正确预测变化，完美封装变化

  8. 低成本本质是与高性能和高可用性冲突的， 首先定成本目标再设计架构.

  9. 架构设计原则：合适原则，简单原则，演化原则

  10. 合适原则：合适优于业界领先 。 将军难打无兵之战，没那么多人却想干那么多活；罗马不是一天建成的，没那么多积累却想一步登天；冰山下面才是关键，没那么多卓越的业务场景，却幻想灵光一闪成为天才。 真正优秀的架构师的都是在企业当前人力，条件，业务等各种约束下设计出来的，能够合理的将资源整合在一起并发挥出最大功效，并且能够快速落地。

  11. 原则: 简单优于复杂。 结构复杂带来的问题：某个组件故障导致整个系统故障， 组件改动影响关联组件，定位故障困难。 逻辑复杂：单个组件承担了太多的功能，带来的问题：系统 庞大clone代码时间长，几十人维护代码，分支合并覆盖，版本冲突...

  12. 演化原则：演化优于一步到位。首先设计出来的架构要满足的当时的业务需要，其次架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善，最后当业务发生变化时，架构要扩展重构甚至重写，代码也许会重写，但有价值的经验教训逻辑设计等却可以在新架构中延续。 时刻提醒自己不要贪大求全，不能盲目照搬大公司的做法，而是应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要。

  13. 架构设计是有套路的，按照套路去做，即使没有丰富的架构设计经验，也能做出基本可行的架构

  14. 架构设计流程：识别复杂度，设计备选方案，评估和选择备选方案

  15. 360度环评：列出我们 需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。常见的方案质量属性点有：性能，可用性，硬件成本，项目投入，复杂度，安全性，可扩展性等。在评估这些质量属性时，需要遵循架构设计原则合适简单，避免贪大求全。选择最终方案时应该按照优先级选择。

  16. 读写分离难点在于解决复杂延迟问题：写操作后的读操作指定发给数据库主服务器；读从机失败后再读一次主机；关键业务读写操作全部指向主机，非关键业务采用读写分离。 方案淘宝TDDL MySQLRouter,Atlas

  17. 分库分表 带来的问题：join操作，事务问题，成本问题。新系统不建议直接分库分表。

  18. 常见的NOSQL方案有如下4类： K-V存储，解决关系数据库无法存储数据结构的问题，以Redis为代表； 文档数据库，解决关系数据库强Schema约束的问题，以MongoDb为代表；列式数据库，解决关系数据库大数据场景下的IO问题，以HBase为代表；全文搜索引擎，解决关系数据库的全文搜索性能问题，以 Elasticsearch为代表

  19. Redis ACID分析

    1）Atomicity原子性，Redis事务不支持原子性，Redis不支持回滚操作，事务中间一条命令执行失败，既不会导致前面已经执行的命令被回滚，也不会中断后面的命令的 执行

    2）Consistency一致性，Redis事务能保证事务开始之前和事务结束以后，数据库的完整性没有被破坏

    3）Isolation性，Redis不存在多个事务的问题，因为Redis是单进程单线程的工作模式

    4）Durability持久性，Redis提供了两种持久化的方式，RDB和AOF

  20. 文档数据库明显的优势： 新增字段简单， 历史数据不会出错， 可以很容易存储复杂数据。 缺点是不支持事务，无法实现Join操作

  21. 列式数据库，节省存储空间，压缩率高。 适用于离线大数据分析统计场景，数据写入后就不再更新删除。

  22. 全文搜索引擎，倒排索引Inverted index

  23. PPC模式，Process per Connection

  24. TPC模式，Thread Per Connection

  25. Reactor模式，IO多路复用结合线程池。1）当多条连接公用一个阻塞对象后，进程只需要一个阻塞对象上等待，而无须再轮询所有连接 2）当某条连接有新的数据可以处理时，操作系统会通知进程，进程从阻塞状态返回，开始进行业务处理

  26. 负载均衡：DNS，硬件负载F5，软件负载Ngnix LVS

  27. 负载均衡算法：轮询，加权轮询，负载最低优先，性能最优类（响应快的多分配）， Hash类

  28. CAP 一致性Consistency。All nodes see the sanme data at the same time. 所有节点在同一时刻看到相同的数据。 A read is guaranteed to return the most recent write for a given client. 对某个客户端来说，读操作保证能返回最新的写操作结果。

  29. CAP 可用性Avaliablity. Every request gets a response on success/faiture. 每个请求都能得到成功或失败的响应。 A non-failing node will return a reasonable respoinse within a reasonable amount of time(no error or timeout) 非故障的节点在合理的时间内返回合理的响应(不是错误或超时)

  30. CAP 分区容忍性Partion tolerance. System continues to work despite message loass or partial failure.尽管出现消息丢失或分区错误，但系统能够继续运行。 The system will continue to function when network partitions occur. 当出现网络分区后，系统能够继续履行职责

  31. 分布式环境网络本身不是100%可靠，所以必须选择P

    image-20240324232638902

  32. Base--- basically Available， Soft state,Eventually Consistency. 即使无法做到强一致性，也要达到最终一致性Eventual Consistency.

  33. 分布式事务算法 2PC（请求，执行） 3PC（请求，准备，执行）

  34. 分层架构，是否应该自由选择是否绕过分层的约束呢？不建议这样做，时间一长架构变得混乱。

  35. SOA提出的背景是 企业内部的IT系统重复建设且效率底下。 ESB Enterprise Service Bus企业服务总线，屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。当ESB承载消息太多时，ESB本身会成为整个系统的性能瓶颈。

  36. 微服务的最佳实践。 服务粒度：三个火枪手原则，新开发阶段一个微服务三个人负责开发。 拆分方法：基于业务逻辑，基于可扩展性（稳定的在一起），基于可靠性（可靠性高的一起），基于性能。 基础设施：服务发现，服务路由，服务容错，服务监控，服务跟踪，服务安全，自动化测试，自动化部署，配置中心，接口框架，API网关

  37. 微内核 MicroKernel Architecutre ,通常包含两类组件：核心系统，插件模块。 代表Eclipse. 关键技术：插件管理，插件连接，插件通信

  38. 规则引擎 也属于微内核架构的一种具体实现， JBoss Drools。通常情况下对Drools进行封装，做成可视化

  39. 识别复杂度， TPS 一秒写入量， QPS一秒读出量。 峰值一般取平均值的3倍，系统设计目标按照峰值的4倍计算。

  40. 企业业务分为两类：一类是产品类（360 Iphone UC），一类是服务类(百度，淘宝，新浪)。 产品类是 技术创新推动业务发展。 服务类是 业务发展推动技术的发展。 服务类的业务发展路径是这样的：提出一种创新的服务模式-》吸引一批用户-》业务开始发展-》吸引更多用户-》服务模式不断的完善创新-》吸引越来越多的用户。

  41. image-20240324232700886

  42. 服务中心的两种方式： 服务名字系统（A访问B时先询问地址，服务中心返回地址后，直接访问到B）， 服务总线系统（A直接请求服务中心，服务中心请求B，B返回服务中心，服务中心 返回A）

posted @ 2024-03-24 23:32  changlong2022  阅读(31)  评论(0)  编辑  收藏  举报