技术角 | 架构学习书摘总结（五）架构实战（上）

最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。

本文是该书第五部分上半部分，是书中第十六章、第十七章，主要介绍消息队列设计、互联网架构演进等架构实际案例内容。

目录

▪第十六章 消息队列设计实战

▪第十七章 互联网架构演进

▪其他相关摘要

第十六章 消息队列设计实战

1. 需求：
   1. 用户发微博，通过审核子系统、统计子系统、广告子系统、消息子系统等，系统间通过接口调用，每通知一个新系统，微博子系统就要涉及接口进行测试，效率很低，问题定位很麻烦。还有等级子系统给VIP用户发放奖励、通知客服子系统安排专属服务人员……开发人员不胜其烦。
   2. 根因在于架构上各业务子系统强耦合，而消息队列正好可以完成子系统的解耦。经过一分析二讨论三开会四汇报五审批等一系列操作后，消息队列系统立项。
2. 设计流程：
   1. 这个消息队列是否需要高性能：关注每秒数据，即TPS和QPS。再考虑系统的读写并不是完全平均的，设计的目标应该以峰值来计算。峰值一般取平均值的3倍。例如，一天平均每秒写入消息为115条，每秒读取消息数是1150条，则消息对类系统的TPS是345，QPS是3450。另外由于现在基数较低，因此系统的设计目标按照峰值的四倍来计算，即TPS为1380，QPS为13800。TPS为1380并不高，但QPS为13800已经比较高了，因此高性能读取是复杂度之一，但这个高性能要求相比Kafka等系统来说也不是很高。
   2. 这个消息队列是否需要高可用：消息队列需要高可用性，包括消息写入、消息存储、消息读取都需要保证高可用性。
   3. 这个消息队列是否需要高可扩展性：消息队列的功能很明确，基本无需扩展，因此可扩展性不是这个消息队列的复杂度关键。
   4. 识别复杂度：对架构师来说是一项挑战，如果经验不足，那么只能采取“排查法”，从不同角度逐一进行分析。对于此项目具体分析过程如下： 综合分析下来，消息队列的复杂性主要体现在几个方面：高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。
   5. 设计备选方案：采用开源Kafka、集群+MySQL存储、集群+自研存储方案。
   6. 评估和选择备选方案 质量属性引入KafkaMySQL存储自研存储性能高中高复杂度低，基本开箱可用中，MySQL存储和复制，方案只需要开发服务器集群就可以高，自研存储方案复杂度很高硬件成本低高，一个分区就4台机器低，和Kafka一样可运维性低，无法融入现有的运维体系，且运维团队无Scala经验高，可以融入现有运维体系，MySQL运维很成熟高，可以融入现有运维体系，并且只需要维护服务器即可，无需维护MySQL可靠性高，程序开源方案高，MySQL存储很成熟低，自研存储系统可靠性在最初阶段难以保证人力投入低，开箱即用中，只需要开发服务器集群高，需要开发服务器集群和存储系统最终根据讨论与架构师决策，选择了备选方案2。
   7. 细化方案：在备选方案的基础上进一步细化。

第十七章 互联网架构演进

1. 什么样的策略才是真正有效的技术发展策略这个问题让人困惑关键的原因在于不管是潮流派（紧跟技术潮流）、保守派（新技术抱有戒备心，稳定压倒一切），还是跟分派（跟着竞争对手的步子走），都是站在技术本身的角度来考虑问题的，正所谓“不识庐山真面目，只缘身在此山中”。因此，要想看到“庐山真面目”，只有跳出技术的范畴，从一个更广更高的角度——企业的业务发展来考虑这个问题。
2. 企业的发展，归根结底就是业务的发展，而影响一个企业的发展主要有3个因素：市场、技术、管理。在这个铁三角当中，业务处于三角形的中心，毫不夸张的说，市场、技术、管理都是为了支撑企业业务的发展。
3. 我们可以简单地将企业的业务分为两类：产品类和服务类。
4. 对于产品类服务，技术创新推动业务发展。对于服务类服务，业务发展推动技术发展。两类不同关系的原因在于用户选择服务的根本驱动力与选择产品的不同。用户选择一个产品的根本驱动力是其“功能”，而用户选择一个服务的根本驱动力却为“规模”。
5. 当“规模”成为业务的决定因素后，服务模式的创新就成为业务发展的核心驱动力，而产品只是为了完成服务而提供给用户使用的一个载体。
6. 服务类的业务发展路径：提出一种创新的服务模式→吸引了一批用户→业务开始发展→吸引了更多用户→服务模式不断完善和创新→吸引越来越多的用户。
7. 即使是产品类业务，在技术创新开创了一个新的业务后，后续的业务发展也会反向推动技术的发展。
8. 对于架构师来说，判断业务当前和接下来一段时间的主要复杂度是什么是非常关键的。架构师具体应该按照基于业务发展阶段的标准进行判断，这也是为什么架构师必须具备业务理解能力的原因。
9. 互联网业务具有“规模决定一切”的相同点。
10. 互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。不同时期的差别主要体现在两个方面：复杂性、用户规模。
11. 互联网发展的第一个主要方向是“业务越来越复杂”。 初创期业务重点在于创新，只有随着越来越多的用户的使用，通过快速迭代试错、用户的反馈等手段，不断地在实践中去完善，去继续创新。 发展期主要是将原来不完善的业务逐渐完善，因此会有越来越多的新功能不断地加入系统中。对于绝大部分技术团队来说，这个阶段技术的核心工作是快速地实现各种需求，只有这样才能满足业务发展的需要。 架构期进行架构调整，架构期可以用的手段很多，但归根结底可以总结为一个字“拆”，功能、数据库、服务器等什么地方都可以拆。 竞争期对技术的要求更上一层楼的“快”了，新业务的创新给技术带来的典型压力就是新的系统会更多，同时，原有的系统也会拆得越来越多。两者合力的一个典型后果就是系统数量在原来的基础上又增加了很多。而系统越来越多到了一个临界点后就产生到了质变，即系统数量的量变带来了技术工作的质变。主要有重复造轮子、系统交互一团麻。这个时期技术工作的主要解决手段有平台化（存储平台化、数据库平台化、缓存平台化）、服务化（消息队列、服务框架等）。 成熟期进行逐项优化。
12. 互联网发展的第二个主要方向是“用户量越来越”大。主要影响体现在：性能要求越来越高、可用性要求越来越高。 性能：再简单的查询，再高的硬件配置，单台MySQL机器支撑的TPS和QPS最高也就是万级，低的可能是几千，高的也不过几万。分布式将会带来复杂度的大幅度上升。以MySQL为例，分布式MySQL要考虑分库分表、读写分离、复制、同步等很多问题。 可用性：除了口碑，可用性对收入的影响也会随着用户量增大而增大。1万用户宕机1小时，可能才损失了几千元，100万用户宕机10分钟，损失可能就是几十万元了。

其他相关摘要

1. 实际中，不同的公司或团队，可能还有一些其他方面的复杂度分析。例如，金融系统可能需要考虑安全性，有的公司会考虑成本等。
2. 通常情况下，成熟的团队不会轻易改变技术栈，反而是新成立的技术团队更加倾向于采用新技术。
3. 架构师的技术储备越丰富，经验越多，备选方案也会更多，从而才能更好地涉及备选方案。
4. 备选方案的选择和很多因素有关，并不单单考虑性能高低、技术是否优越这些纯技术因素。业务的需求特点、运维团队的经验、已有的技术体系、团队人员的技术水平都会影响备选方案的选择。