架构的演化大多通过架构重构来完成。 主要难点体现： 业务已上线（不能停止服务） 相关方多 旧架构的约束 旧数据，旧依赖，旧标准规范 从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。 判断到底是采取架构重构还是采取系统优化 ? 一个简单的做法：假设我们现在需要从 0 开始设计当前系统，新架构和老架构是否类似？如果差异不大，说明采取系统优化即可；如果差异很大，那可能就要进行系统重构了. 那原来发现的那些非架构重构问题怎么办呢？ 重构完，可以再启动多个项目进行优化
2020, Jun 01 — 1 minute readInnoDB 非叶子节点上没有实际的数据 叶子节点上才有实际的数据 叶子节点之间有指针串联指向下一个叶子节点，这样能够提升范围查询的效率 聚簇索引（Clustered） 在InnoDB使用了聚簇索引（Clustered），即所有二级索引聚集在主键索引上，对InnoDB存储引擎表的任何访问，最终一定要搜索主键索引树. 在InnoDB中，二级索引（所有不是主键索引的索引）上没有实际的数据，取而代之的是主键索引的值。 如果是基于二级索引的查询，会先在二级索引上搜索得到主键索引的值，然后再去主键索引树上搜索，得到最终的行数据. 例如：一个表有两个字段 ‘id’,’name’,id是主键，name建立了索引，查询name得到id，再通过id获取到name。 意味至少有一次索引查找，可能会有两次索引查找，其中一定有一次主键索引查找。 ` 在InnoDB中，主键要设计的尽量小，主键越小，二级索引也会越小。 满足需求的情况下，SMALLINT优先于INT，INT优先于BITINT，INTEGER类型优先于VARCHAR类型。 `...
2020, Jun 01 — 1 minute readFeign远程调用的基本流程 https://github.com/OpenFeign/feign/tree/master/core/src/main/java/feign 在微服务启动时，Feign会进行包扫描，对加@FeignClient注解的接口，按照注解的规则，创建远程接口的本地JDK Proxy代理实例。然后，将这些本地Proxy代理实例，注入到Spring IOC容器中。当远程接口的方法被调用，由Proxy代理实例去完成真正的远程访问，并且返回结果。 ` @FeignClient 远程调用接口 → JDK Proxy 动态实例代理 → InvokeHandler →...
2020, May 31 — 1 minute read基本架构 微内核架构包含两类组件： 核心系统（core system） 核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等; 插件模块（plug-in modules）。 插件模块负责实现具体的业务逻辑; 核心系统 Core System 功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断地扩展。 微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定. 设计关键点 插件管理核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。...
2020, May 31 — 1 minute read关于SOA与微服务的区别大多有以下几个观点： 观点1：SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法 例如，“微服务就是使用 HTTP RESTful 协议来实现 ESB 的 SOA”“使用 SOA 来构建单个系统就是微服务”和“微服务就是更细粒度的 SOA”。...
2020, May 31 — 1 minute readNon-blocking Synchronization 1. Wait-free Wait-free 是指任意线程的任何操作都可以在有限步之内结束，而不用关心其它线程的执行速度。 Wait-free 是基于 per-thread 的，可以认为是 starvation-free 的。非常遗憾的是实际情况并非如此，采用 Wait-free 的程序并不能保证 starvation-free，同时内存消耗也随线程数量而线性增长。目前只有极少数的非阻塞算法实现了这一点。 2. Lock-free Lock-Free 是指能够确保执行它的所有线程中至少有一个能够继续往下执行。由于每个线程不是 starvation-free 的，即有些线程可能会被任意地延迟，然而在每一步都至少有一个线程能够往下执行，因此系统作为一个整体是在持续执行的，可以认为是 system-wide 的。所有 Wait-free 的算法都是 Lock-Free 的。 3. Obstruction-free Obstruction-free 是指在任何时间点，一个孤立运行线程的每一个操作可以在有限步之内结束。只要没有竞争，线程就可以持续运行。一旦共享数据被修改，Obstruction-free 要求中止已经完成的部分操作，并进行回滚。所有 Lock-Free 的算法都是 Obstruction-free 的。 综上所述，不难得出 Obstruction-free 是 Non-blocking synchronization 中性能最差的，而 Wait-free 性能是最好的，但实现难度也是最大的，因此 Lock-free 算法开始被重视，并广泛运用于当今正在运行的程序中，比如linux内核。 一般采用原子级的 read-modify-write 原语来实现 Lock-Free 算法，其中 LL 和 SC 是 Lock-Free 理论研究领域的理想原语，但实现这些原语需要 CPU 指令的支持，非常遗憾的是目前没有任何 CPU 直接实现了 SC 原语。根据此理论，业界在原子操作的基础上提出了著名的 CAS（Compare - And - Swap）操作来实现 Lock-Free 算法，Intel 实现了一条类似该操作的指令：cmpxchg8。
2020, May 19 — 1 minute read三板斧 慢查询日志 分场景开启，一般在自测，内测前开启 生产环境不建议开启 explain执行计划 show profile 表与索引的存储方式 B+Tree，高度及广度带来的问题。这个单独写篇文章进行描述。 索引 大多数情况，一个简单的sql只能用到一个索引 简单：不包含子查询或者JOIN的sql mysql内部进行索引带价计算，选择区分度大的索引，和SQL里面and的顺序无关 建立合适的索引 Index...
2020, Feb 09 — 5 minute read先放着大纲，趁宅在家，慢慢写 这个架构图能覆盖大多数互联网公司的技术点： 存储层 SQL 一般情况下互联网行业都是用 MySQL、PostgreSQL 这类开源数据库。 这类数据库的特点是开源免费，拿来就用；但缺点是性能相比商业数据库要差一些。 但随着性能要求越来越高，分表拆库多实例是必然的方向，包括Oracle也是，只是时间早晚的事。 但分表拆库多实例带来复杂度的问题：数据如何拆分、数据如何组合？这个复杂度的问题解决起来并不容易，如果每个业务都去实现一遍，重复造轮子将导致投入浪费、效率降低，业务开发想快都快不起来。 所以互联网公司流行的做法是业务发展到一定阶段后，就会将这部分功能独立成中间件。例如百度的 DBProxy、淘宝的 TDDL。 将分库分表做到自动化和平台化，一般是规模很大的公司才会自己做。 中小公司建议使用开源方案，例如...
2020, Feb 07 — 2 minute read