架构整洁之道笔记
最早的《The Clean Architecture》诞生于 2012年，这个问题很早就被讨论清楚了。
思维导图：
注意，所有的接口都是在高层声明的：UseCase Input Port 和 UseCase Output port，所以高层可以实现高层的接口，低层也可以实现高层的接口。
注意，sofa的分层就是在一个横向的模块里声明了业务用例的接口和 core-model 的接口，这样源代码级的依赖都集中在抽象上：
Use Case Interactor 和 Presenter 应该是可测试的，而 Data Access Interface、View、ORM 应该是 humble object。所以一个应用的低层（外层）应该是被排除掉不做测试的。
附件下载：
xmind
关于源代码中的依赖关系的一些澄清：
“使用”并不意味着“定义”，而只是引用
dashed outline 代表虚线框，也代表抽象。
Petroware 的 Unit Testing Guidelines
Keep unit tests small and fast
Ideally the entire test suite should be executed before every code check in. Keeping the tests fast reduce the development turnaround time.
让单元测试保持小和快。
最完美的是，整个测试套件应该在每次代码被签入的时候被执行。让测试保持快速减少了开发的周转时间。
点评：小的测试是低成本测试。
Unit tests should be fully automated and non-interactive
The test suite is normally executed on a regular basis and must be fully automated to be useful. If the results require manual inspection the tests are not proper unit tests.
单元测试应该是全自动化且无交互的。
...
《应用架构之道》笔记
架构师的职责化繁为简。架构师是职责就是把复杂的问题简单化，使得其他人能够更好地在架构里工作。
架构师要努力训练自己的思维，用它去理解复杂的系统，通过合理的分解和抽象，做出合理的设计。
软件架构软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。
软件架构为软件系统提供了结构、行为和属性的高级抽象。，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。
软件架构的核心价值应该只围绕一个核心命题：控制复杂性。
软件架构分类
业务架构：由业务架构师负责，也可以称为业务领域专家、行业专家。业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。
应用架构：由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时， ...
（转）程序员的成长路线
工作这么些年了，看到了各种各样的程序员，也看到了各种各样的成长路线，说说自己的一些观点吧。
作为技术人员，在刚起步阶段时，首先需要拓宽自己的技术宽度，对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解，另外对于就是学习工程化，让自己真正具备开发商业软件的能力。
在工程化和知识宽度达到一定阶段后，需要开始根据自己的兴趣和工作内容有所选择，主要是加强在某一领域的技术深度。
在技术深度达到了一定阶段后，需要对自己做出一个选择，就是偏业务方向，还是偏基础技术方向。
偏业务方向的技术人员，我认为做的好的表现是：
对业务发展的未来有一定的预判，有商业敏感意识；
能对复杂的业务进行合理的抽象；
在系统的设计上能对未来业务的变化有一定的预留处理。
偏基础方向的技术人员，我认为做的好的表现是：
能结合业务的发展趋势对基础技术的方向有一定的预判，避免业务发展受到基础技术的拖累；
对业界的技术发展方向有自己的认知和判断；
在对应的基础技术领域有不错的技术深度。
结合自己的特质以及当前的一些状况，做出一个选择，重点发展。
而再往更高阶走的同学，通常就会出现一种新的角色，就是成为团队leader ...
重述双亲委派模型
何时加载类
遇到 new、getstatic、putstatic 等指令时。
对类进行反射调用的时候。
初始化某个类的子类的时候。
虚拟机启动时会先加载设置的程序主类。
使用 dynamic 动态语言支持等相关特性时。
从 Java 到 cpp 源码分析
JVM默认用于加载用户程序的ClassLoader为AppClassLoader，不过无论是什么ClassLoader，它的根父类都是java.lang.ClassLoader。在上面那个例子中，loadClass（）方法最终会调用到ClassLoader.definClass1（）中，这是一个Native 方法。
12static native Class<?> defineClass1(ClassLoader loader, String name, byte[] b, int off, int len, ProtectionDomain pd, String source);
definClass1（）对应的 JNI 方法为 Jav ...
《流水型 FO》笔记
数据的分类状态型数据，需要三地五中心容灾，需要强一致性，事务延迟较高。对状态型数据的操作实际上是对同一行记录进行反复操作。
流水型数据，对历史数据依赖较少，每一笔业务相对独立。
基于一定的业务理解和假设，我们可以设计出一套新的模型和存储方案，实现流水型 FO。
部署形态通常流水型 FO 要求部署三套库。
主库
LFO 库 同城 FO。承担机房级故障。
RFO 库，异地 FO 库。承担区域
数据格式8 位日期 + 1 位数据版本 + 1 位系统版本 + 3 位系统标识 + 2 位预留 + 2 位 uid + 2 位弹性位 + 8 位 sequence
设计数据格式影响几个问题：
1 当系统发生一笔流水的时候，流水应该落到哪个库里去。2 当我需要一笔流水时，我应该从哪个库里面查询这笔流水。
有关联关系的单据，如果发生弹性切换，要保证正逆向流程的单据都弹到一个库里。
流水型 FO 方案如何做到业务无感知？？？？
流水型 FO 发生强切的时候如何保证业务业务无损？？？？
《结构化的思考、做事、成长》笔记
能力要素要重点建设的三种能力：
结构化的思维
结构化的工作模式
结构化的能力建设
什么是结构化structured：建立中心（问题、目标）以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制定行动计划。
同理，按照逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳归总成一个中心，也是结构化。
案例建立结构化的中心一个业务需求，通常可以按照两个维度分解为不同的子结构：
1 当前业务需求的目标是什么？（事的维度）。
目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线。
目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案。
2 为什么需要我来做？（人的维度）
是因为我工作量还有 buffer 所有承担这部分：目标人的维度是完成职能范畴内的工作。
是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。
沿中心上行对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构树的基础。但我们 ...
《JVM 问题分析处理总结》笔记
知识体系图谱
紧急处理原则出现问题应该第一时间恢复，恢复过程中如果有余地则要保留问题现场供后面排查定位问题，其基本步骤是：
打印堆栈信息
打印内存镜像
生成core文件
保留gc日志文件
保留业务日志文件
查看JAVA堆内存运行分配
如果有余地，可以做完以上的操作后再重启应用。
实例实例一1 查看 gc 日志，评估代际问题。2 查看访问日志，看看应用吞吐量。3 用 jstat 查看代际问题。4 把内存 dump 出来，分析数量最多的对象。5 分析代码。6 改善代码。
实例二1 统计线程总数：ps -eLf | grep java -c2 看 ulimit -u3 jstack、gcore4 改善 jvm 参数
《高可用恢复思路》笔记
遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求：
限流保护。抵挡来自突发流量冲垮整个集群。
降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。
削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。
这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。
以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设：
发现机制，是我们的眼睛，也是基础。
监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。
主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。
快速恢复
根据监控快速寻找问题发生的方向和位置。
找对恢复的人、恢复的预案。
倾向于选择成本低的恢复手段。—— 并不是所有的恢复都用大招（熔断、限流），大招一定有 ...
