Lanchester Blog

当内存分配的时候，剩余的空间不能满足要分配的对象时就会优先触发新生代回收（Young GC，YGC）。G1的 YGC 收集的内存是不固定的，每次回收的内存可能并不相同，即每次回收的分区数目是不固定的，但是每一次 YGC 都是收集所有的新生代分区，所以每一次 GC 之后都会调整新生代分区的数目。

通常我们所说的 GC 是指垃圾回收，但是在 JVM 的实现中 GC 更为准确的意思是指内存管理器，它有两个职能，第一是内存的分配管理，第二是垃圾回收。这两者是一个事物的两个方面，每一种垃圾回收策略都和内存的分配策略息息相关，脱离内存的分配去谈垃圾回收是没有任何意义的。

Flowable 高级用法

Flowable 是一个使用 Java 编写的轻量级业务流程引擎。Flowable 流程引擎可用于部署 BPMN 2.0 流程定义（用于定义流程的行业 XML 标准）， 创建这些流程定义的流程实例，进行查询，访问运行中或历史的流程实例与相关数据，等等。

Flowable 工具集搭建

共识指的是让参与的节点对某些决定达成共识。共识算法满足以下条件：

• 统一协议。所有节点都得出相同的结论。
• 整体性。没有节点会做两次决定。
• 有效性。如果决定是 X，那么 X 必定是某个节点建议的。
• 终止性。任何没有宕机的节点最终都会达成一致。

如果你不关心容错，可以很容易满足以上三个指标，比如指定一个 master 做所有的决定。但是，一旦 master 挂掉，那么系统将不能再做任何决定。这就是我们在2PC中看到的情况：如果协调者失败，那么参与者会一直等待。

终止性主要出现在容错的情况下。在节点故障的环境里，共识算法不能停滞不前，应该也能做出决定。模型认为一个失联的节点再也不会回来，能够基于此继续作出决定。显然，2PC 是不满足这个条件的。当然，所有节点都宕机了，是不可能做出决定的，算法会对宕机节点有一个限制，经过证明任何共识算法只要在一半以上节点正常时就可以正常工作。另外，大部分共识算法默认系统没有出现拜占庭故障（节点异常，比如发送不同的提议道不同的节点）。

实际生产中，常见的共识算法实现包括 VSR、Paxos、Raft 和 Zab。这些算法细节实现不尽相同，但是都遵循着相同的设计原理。这些算法一般不会直接使用我们描述的单一值决策流程，而是对一系列值作出决定，并满足全局有序的条件，就好像做了多轮的单一值共识算法。

即使只限定在“软件架构设计”这个语境下，系统安全仍然是一个很大的话题。我们谈论的计算机系统安全，不仅仅是指“防御系统被黑客攻击”这样狭隘的安全,，还至少应包括（不限于）以下这些问题的具体解决方案：

• 认证（Authentication）：系统如何正确分辨出操作用户的真实身份？
• 授权（ Authorization）：系统如何控制一个用户该看到哪些数据、能操作哪些功能？
• 凭证（Credential）：系统如何保证它与用户之间的承诺是双方当时真实意图的体现，是准确、完整且不可抵赖的？
• 保密（Confidentiality）：系统如何保证敏感数据无法被包括系统管理员在内的内外部人员所窃取、滥用？
• 传输（Transport Security）：系统如何保证通过网络传输的信息无法被第三方窃听、篡改和冒充？
• 验证（Verification）：系统如何确保提交到每项服务中的数据是合乎规则的，不会对系统稳定性、数据一致性、正确性产生风险？

与安全相关的问题，一般不会直接创造价值，解决起来又烦琐复杂，费时费力，因此经常性被开发者有意无意地忽略掉。庆幸的是这些问题基本上也都是与具体系统、具体业务无关的通用性问题，这意味着它们往往会存在着业界通行的、已被验证过是行之有效的解决方案，乃至已经形成行业标准，不需要开发者自己从头去构思如何解决。

Java SPI 机制（Service Provider Interface）是动态加载 Service 服务的机制。我们能使用 ServiceLoader 实现 Java SPI 机制在我们应用中根据一系列规则加载服务。

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的 非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、 可观测性、灰度等)，使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

微服务架构是由大型单体服务拆分为小型服务的哲学，其需要以下四个设计原则：服务化、流量治理、可靠通讯、可观测性。