《应用架构之道》笔记
架构师的职责 化繁为简。架构师是职责就是把复杂的问题简单化,使得其他人能够更好地在架构里工作。 架构师要努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,做出合理的设计。 软件架构 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件的链接则明确和相对细致地描述组件之间的通信。 软件架构为软件系统提供了结构、行为和属性的高级抽象。,由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系,而且指定了整个软件系统的组织和拓扑结构,提供了一些设计决策的基本原理。 软件架构的核心价值应该只围绕一个核心命题:控制复杂性。 软件架构分类 业务架构:由业务架构师负责,也可以称为业务领域专家、行业专家。业务架构属于顶层设计,其对业务的定义和划分会影响组织结构和技术架构。 应用架构:由应用架构师负责,他需要根据业务场景的需要,设计应用的层次结构,制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平,从而在快速的支撑业务发展的同时,在保证系统的可用性和可维...
(转)程序员的成长路线
工作这么些年了,看到了各种各样的程序员,也看到了各种各样的成长路线,说说自己的一些观点吧。 作为技术人员,在刚起步阶段时,首先需要拓宽自己的技术宽度,对自己所做的项目/产品所涉及的方方面面的技术都应该有所了解,另外对于就是学习工程化,让自己真正具备开发商业软件的能力。 在工程化和知识宽度达到一定阶段后,需要开始根据自己的兴趣和工作内容有所选择,主要是加强在某一领域的技术深度。 在技术深度达到了一定阶段后,需要对自己做出一个选择,就是偏业务方向,还是偏基础技术方向。 偏业务方向的技术人员,我认为做的好的表现是: 对业务发展的未来有一定的预判,有商业敏感意识; 能对复杂的业务进行合理的抽象; 在系统的设计上能对未来业务的变化有一定的预留处理。 偏基础方向的技术人员,我认为做的好的表现是: 能结合业务的发展趋势对基础技术的方向有一定的预判,避免业务发展受到基础技术的拖累; 对业界的技术发展方向有自己的认知和判断; 在对应的基础技术领域有不错的技术深度。 结合自己的特质以及当前的一些状况,做出一个选择,重点发展。 而再往更高阶走的同学,通常就会出现一种新的角色,就是成为团队lea...
重述双亲委派模型
何时加载类 遇到 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 ...
《流水型 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 -c 2 看 ulimit -u 3 jstack、gcore 4 改善 jvm 参数
《高可用恢复思路》笔记
遇到线上问题,经常陷入一个误区:一定要找到问题的根因(root cause)。但实际上对线上应用而言,最重要的是恢复可用性,所以在开发设计环境除了完成功能性需求以外,还需要加入非功能性设计的需求: 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护,对调用的服务接口保持警惕,其各种因素导致不可用,可以对齐降级,从而确保核心功能可用。 削峰填谷(traffic shaping),不因突发数据来袭,造成任务消费陡增,造成调用系统的连串抖动。 这些基本的系统保护,是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计,问题的发现机制,也需要结构化地考虑,体系化地建设: 发现机制,是我们的眼睛,也是基础。 监控主指标,需要找对业务的主要指标,常见的主指标一般是:RT(响应时间)、总量、成功量、失败量、成功率。 主指标有异常,还要有细分维度(即结果还可以内部 group by aggregation)。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。---- 并不是所有的恢复都用大招(熔断、限流),大招...
如何进行域划分
1 用户需求场景分析,识别业务全景 use case。这一个阶段重点识别 actor 和 use case。 2 分析模型鲁棒图,识别出业务场景中所有的实体对象。识别边界类(类似 ui)、控制类(类似 controller)和实体类(类似model)三种类型。 3 领域划分,将所有识别出的实体对象进行分类。 比如,主订单、子订单对象和归类到交易域;买家、卖家对象可以归类到会员域。 当然,最终所有的对象是归类到十个域还是二十个域,从理论上看,可以看做一次排列组合过程。只是,我们往往可以根据以往的经验、业务知识,做一个初始的域划分(但不见得是靠谱的)。因此,我们可以认为一个域实际上是一个或多个实体对象的信息集合,并对所管理的实体对象的生命周期进行管理。 4 评估域划分合理性,并进行优化。域划分并一定总是能得到唯一的答案,但可以得到最好的答案。评价一个域划分方案是不是足够好,其实是要根据“高内聚、低耦合”的原则进行评分。这一步就要画时序图了。 时序图的泳道,应该先设计到域颗粒度。可以看到域之间的交互,也就可以看到域之间的交互的复杂度。在绘制过程中,我们可以看域与域之间的调用是否过于频繁...
Differences between Proxy and Decorator Pattern
https://stackoverflow.com/questions/18618779/differences-between-proxy-and-decorator-pattern https://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator is assigned to the subjec...















