许式伟的架构课
首先，基础架构是业务架构的一部分。不了解基础架构，你就不知道自己写的软件背后都发生了什么，你就无法掌控全局，这对你思考架构演进会有很大的局限性，因为你是 “戴着脚镣跳舞”。
其次，基础架构是最宏大的架构实践案例，需要我们好好感悟。我们不只是要知道基础架构怎么用，还应该理解它为何演变成今天这样。对于优雅的基础架构设计，我们应该要有强烈的共鸣，惊喜赞叹。如果你没有感觉，说明你对架构思维也还没有感觉，也就更不可能构建出极致的架构。
一个架构师需要掌握的三个技能:
- 理解代码的能力
- 读代码的能力
- 抽象系统的能力
架构思维
服务治理
- sre 变更是故障之源
- 一个完善的监控系统，并不是 “报警很多很完善” 的系统，而是 “信噪比高，有故障就报警，有报警就直指根因” 的监控系统。
- 监控的4个指标:延迟、流量、错误和饱和度
- 通过采样+汇总可以降低成本
- 少就是指数级的多
- 灰度发布，减少风险
- 针对长期会有风险的故障，需要进行严格的白盒代码审核和全面的覆盖率测试
- 日志有助于故障排查
- 过载后如何保护系统
- 过载如何监控系统，可以基于某个资源的阈值比如CPU，而不仅仅是基于QPS设定
未来服务端技术的演进会走向何方？服务治理系统的迭代，最终将让我们达到这样的状态。
- 任何业务都可以轻松达到 7x24 小时不间断服务。高并发？高可用？高可靠？小菜一碟。做业务都足够的傻瓜化。
- 服务端工程师？不存在的，我们要的只是 SQL 工程师。
- 做一个新的有状态的存储中间件虽然比做业务麻烦一点，但是，一方面也没有多少新的存储中间件需要做的，另一方面做一个存储中间件有足够便捷的辅助设施，也不会比今天做一个内存中的哈希表难多少。
最终软件开发不在区分后端和前端
架构设计
架构设计的基本准则
- KISS：简单比复杂好；
- Modularity：着眼于模块而不是框架；
- Testable：保证可测试性；
- Orthogonal Decomposition：正交分解。
其中一个评论感觉也非常重要:
其实还有一种耦合度经常被人忽视，就是技术耦合度。我们相信，无论是今天多么流行的技术，未来都有失去竞争力的一天，但要开一家长达数十年甚至数百年的技术公司，不可能长期使用已经失去竞争力的技术，必然涉及到技术的多次演进。如果公司的关键性产品与某一种技术耦合度太高，则当该技术失去竞争力或彻底淘汰后，技术迁移成本过高，极易造成迁移彻底失败。所以我从不看好那种一个 Git 库里数十万甚至数百万行 xx 语言或者基于 xx 框架编写的代码，要起一个新项目还必须去引用这个库里的代码不可，这种项目不可能活很久。如果这个项目是公司的关键性产品，那么这个公司也活不了很久。
- 比框架（架构图）更重要的是数据结构，比数据结构更重要的是接口。
- 需求分析->概要设计->模块的详细设计
- 任何功能都可已做正交分解
- 核心系统一定要最小化
- 坚持不要往核心系统增加新功能，这样业务系统就不可能有臭味
开闭原则
架构设计的核心工具
- 组合,通过小业务组合大业务
- 开闭原则
开闭原则总结
- 模块的业务要稳定
- 对于模块变化的部分，可以通过回调函数或者接口开发出去。复制点的可以通过插件把系统分解
单一职责原则和开闭原则的区别：
- 单一职责：强调每个模块只负责一个业务
- 开闭原则：强调把模块业务的变化点抽离出来，包给其他的模块
他们说谈论的其实是同一个问题的两面
接口设计准则
- 如无必要，勿增实体
- 对于模块的使用界面，推荐KISS原则
- 对于模块的依赖，遵循最小依赖原则
软件工程
软件工程
- 软件工程是快速变化的，不确定的。软件项目的管理又期望达到确定性。这就是软件工程的核心点
软件外包
- 我们尽可能不要做太多事情。非核心竞争力相关的，能够外包的我们尽可能外包。
- 在外包选择上，我们优先选择云服务，次选开源，最后才考虑传统的外包。