本文字数：2559字
阅读时间：5分钟
最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。
本文是该书第五部分下半部分，是书中第十九章、第二十章，主要介绍架构重构和开源系统等架构实际案例内容。
目录
▪第十九章 架构重构
▪第二十章 开源系统
第十九章 架构重构
- 系统架构是不断演化的，少部分架构演化可能需要推倒重来进行重写，但绝大部分的架构演化都是通过架构重构来实现的。架构重构对架构师的要求更高，主要体现在：
因此架构重构对架构师的综合能力要求非常高，业务上要求架构师能够说服产品经理暂缓甚至暂停业务来进行架构重构；团队上需要架构师能够与其他团队达成一致的架构重构计划和步骤；技术上需要架构师给出让技术团队认可的架构重构方案。
- 业务已经上线，不能停下来
- 关联方众多，牵一发动全身
- 旧架构的约束
- 有的放矢：期望通过架构重构来解决所有问题当然是不现实的，所以架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。尤其是对于刚接手一个新系统的架构师或技术主管来说，一定要控制住“新官上任三把火”的冲动，避免摊大饼式或运动式的重构和优化。架构师需要透过问题表象看到问题本质，找出真正需要通过架构重构解决的核心问题。
- 合纵连横：
- 合纵：要想真正推动一个重构项目启动，需要花费大量的精力进行游说和沟通。一般技术人员谈到架构重构时，就会搬出一大堆技术术语，但如果和非技术人员这样沟通，效果如同鸡同鸭讲，没有技术背景的人员很难理解，甚至有可能担心我们是在忽悠人。所以在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键。例如某系统不用直接说可用性是几个9，而是整理线上故障的次数、每次影响的时长，影响的用户，客服的反馈意见等，然后再拿其他系统的数据进行对比，无论产品人员、项目人员，还是运营人员，明显就看出系统的可用性有问题了。
- 连横：有重构需要和其他相关或配合的系统的沟通协调。由于大家都是做技术的，所以这里沟通协调容易写，但是也有阻力，主要有“这对我有什么好处”和“这部分我这边现在不急”。前者会被误认为“不顾大局”，但其实首先这种拔高一般都比较虚，无法明确，不同人的理解不一样，无法达成共识；其次是如果对公司和部门有利，但对某个小组没用甚至不利，那么可能是因为目前的方案不够好，还可以考虑另外的方案。推动的有效策略是“换位思考、合作双赢、关注长期”，即站在对方角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益。当然有的时候有些情况需要协调更高层级的管理者才能推动，平级推动是比较难的。
- 运筹帷幄：架构师在识别系统关键的复杂度问题后，还需要识别为了解决这个问题，需要做哪些准备事项，或者还要先解决哪些问题。其实就是分段实施，将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源解决一类问题。
制定分段实施策略有如下经验：
- 划分优先级：将明显且有比较紧急的事项优先落地，解决目前遇到的主要问题。
- 问题分类：将问题按照性质分类，每个阶段集中解决一类问题。
- 先易后难：这点与很多人的直觉不太一样，有的人认为应该先攻克最难的问题，所谓的“擒贼先擒王”，解决最难的问题后其他问题就不在话下。这看起来很美好，但实际上不可行。采取先易后难的策略，能够很大程度上避免“先易后难”策略的问题。
- 文武双全：项目管理 技术能力 真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是空谈！“项目管理能力”是“文”的能力，“技术能力”是“武”的能力，架构师必须文武双全才能解决问题。 我们牢记架构设计的目的：架构设计的主要目的是为了解决系统的复杂性。 某些系统关键问题是“不合理的耦合带来的复杂性”：将特定业务的数据和所有业务的公共数据耦合在一起，数据正确性难以保证，而且每次修改都是“牵一发动全身”，效率很高，所以重构的目标就是将“不合理的耦合”进行拆分。 而某些系统主要的问题就是有一个全局单点，一旦这个单点故障，就会导致所有业务全部不可用。所以我们重构的目标就是解决“全局唯一单点”的可用性问题。
第二十章 开源系统
- 开源项目虽然节省了大量的人力和时间，但带来的踩坑（宕机、丢数据等）问题也不少。
- 架构师需要更加聪明的去选择和使用开源项目，即不要重复造轮子，但要找到合适的轮子。
- 选-如何选择一个开源项目：聚焦是否满足业务、聚焦是否成熟（可以看版本号、使用的公司数量、社区活跃度判断）、聚焦运维能力（可以从开源方案日志是否齐全、开源方案是否有命令行管理控制台等维护工具能看到系统运行时的情况、开源方案是否有故障检测和恢复的能力例如告警、倒换等）。
- 用-如何使用开源方案：
- 深入研究，仔细测试。可通过如下几个方面进行研究和测试：
- 通读开源项目的设计文档或白皮书，了解其设计原理。
- 核对没给配置项的作用和影响，识别出关键配置项。
- 进行多种场景的性能测试。
- 进行压力测试，连续跑几天，观察CPU、内存、磁盘I/O等指标波动。
- 进行故障测试，kill、断电、拔网线、重启100次以上、倒换等。
- 小心应用，灰度发布：不管研究多深入、测试多仔细、自信心多爆棚，时刻对线上环境和风险要有敬畏之心，小心使得万年船。经验就是先在非核心的业务上应用，然后有经验后再慢慢扩展。
- 做好应急，以防万一：运气不好可能遇到一个之前全世界的使用者都从来没遇到的bug。
- 深入研究，仔细测试。可通过如下几个方面进行研究和测试：
- 改-如何基于开源项目做二次开发
- 保持纯洁，加以包装：建议不要改动原系统，而是要开发辅助系统：监控、告警、负载均衡、管理等。
- 发明你要的轮子：软件领域和硬件领域最大的不同就是前者没有绝对的工业标准，大家都很尽兴，想怎么玩就怎么玩。除此以外，开源项目未来能够大规模应用，考虑的是通用性的处理方案，而不同的业务其实差异较大，通用方案并不一定完美适合具体的某个业务。所以，如果你有钱有人有时间，投入人力去重复发明完美符合自己业务特点的轮子也是很好的选择。毕竟，很多财大气粗的公司（BAT们）都是这样做的，否则我们也就没有那么多好用的开源项目了。
