庄小焱

本文主要介绍了状态机模型的设计经验，包括其定义、适用场景、建模示例、事件驱动设计以及配置数据化等内容。状态机模型通过事件驱动控制状态变化，适用于流程驱动系统、生命周期管理等场景，不适用于状态变化简单或不确定的场景。文中还提供了基于“信贷审批流程”的项目示例和事件驱动流转的Spring项目示例，最后总结了状态机模式设计的优势。

本文总结了项目设计中提升扩展性的多种方法。首先介绍了使用策略模式、工厂模式和Spring容器组合设计实现多场景多功能支持的高扩展性项目架构，包括目标结构、设计思路和示例代码。接着探讨了更复杂的多维度需求设计，如功能下有多种方式、渠道等，提出需求抽象结构、核心设计目标和Spring Boot实现概览，还涉及通过注解标记处理器、优化分类目录、增加抽象父类简化实现、支持动态注册等优化方法，最后讨论了数据库数据动态加载到Spring中的实现方式和适用场景。

本文主要分享了 Java 开发中的项目设计经验总结，包括 common 包的内容分类及最佳实践建议、RPC 接口的放置位置、引用关系数据模型设计、阿里软件上线发布流程规范和最佳实践以及分布式系统流量东西/南北控制设计等内容，旨在为 Java 开发人员提供项目设计方面的参考和指导。

本文总结了系统设计的项目经验，强调了域的区分、功能区分、类的区分、方法区分范围和定义的重要性。提出类和方法应遵循单一职责原则，必要时进行拆分。介绍了泛型的使用，包括通用类型和具体类型的区分。详细阐述了低耦合和高内聚的概念、特点及实现方法，并通过示例展示了高耦合、低内聚的反例。

大文件传输是指通过网络将体积较大的文件从一个位置发送到另一个位置的过程。这些文件可能包括高清视频、大型数据库、复杂的软件安装包等，它们的大小通常超过几百兆字节（MB）甚至达到几个吉字节（GB）或更大。大文件传输可能面临一些挑战，比如传输速度慢、网络不稳定导致的传输中断、以及存储空间的限制等。为了有效地传输大文件，可能需要使用特定的技术，比如压缩文件以减少传输数据量、使用高速网络连接、或者采用分块传输技术来提高传输的稳定性和效率。

用户通过绑定手机号的注册为会员，并可以补充完个人信息，比如姓名、生日等信息，拿到用户的生日信息之后，就可以通过会员生日信息进行营销，此处就涉及到定时任务执行营销信息推送的问题。本篇就带你走入微服务下的定时任务的构建问题。常见的定时任务的解决方案有以下几种：右半部分基于 Java 或 Spring 框架即可支持定时任务的开发运行，左侧部分需要引入第三方框架支持。针对不同方案，作个简单介绍：引入第三方分布式框架会增加项目复杂度，Timer、TimerTask 比较简单无法符合复杂的分布式定时任务，本次选择基于

大型系统中的都是众多服务相互调用来完成某一项功能，这其中就会涉及到是服务的相互调用和发现功能。本博文主要介绍的服务注册与发现设计。在分析业务需求时，其中有个简单的功能点：会员可以开通月卡，开通月卡的同时，需要增加相应的积分。开通月卡功能在会员服务模块维护，但增加积分功能在积分服务模块维护，这就涉及到两个模块间的服务调用问题。单实例情况：可以采用点对点的 HTTP 直接调用，采用 IP + Port + 接口的形式进行。也可以对外暴露 WebService 服务供外部模块调用，但 WebService 的形式

缓存与队列，是应对互联网高并发高负载环境的常见策略，缓存极大地将数据读写，队列有效地将压力进行削峰平谷，降低系统的负载。实现队列较好的解决方案就是利用消息中间件，但消息中间件绝不止队列这一个特性，还可以应用于异步解耦、消息驱动开发等功能，本博文介绍微服务下的消息驱动开发。消息中间件产品不可谓不多，常见的有 Apache ActiveMQ、RabbitMQ、ZeroMQ、Kafka、Apache RocketMQ 等等，还有很多，具体如何选型，网络中存在大量的文章介绍（这里有一篇官方的文档，与 ActiveM

已经引入 Nacos 基础组件，完成了服务注册与发现机制，可以将所有服务统一的管理配置起来，方便服务间调用。本篇将结合需求点，进行服务间调用，完成功能开发。服务间调用常见的两种方式：RPC 与 HTTP，RPC 全称 Remote Produce Call 远程过程调用，速度快，效率高，早期的 WebService 接口，现在热门的 Dubbo、gRPC 、Thrift、Motan 等，都是 RPC 的典型代表，有兴趣的小伙伴可以查找相关的资料，深入了解下。HTTP 协议（HyperText Transfe

经过前期的需求分析和模型设计与系统架构设计，我们对项目的整体结构有了更清晰的认识，剩下的工作就是依据设计，将项目骨架拉出来，往里面直充血肉。构建起系统中的子微服务模块。约定项目名称为 parking-project ，建立 Maven 项目，packaging 方式 为 pom，用于管理所有模块。在 parking-project 项目下依据功能模块依次建立 maven module 子项目。采用 IDE工具。以 Maven Project 形式创建父项目，用于管理子模块功能。.........

经过前面需求梳理，商场停车收费业务需求情况已经十分明了，本节就依据前文的输出做为输入，开始系统设计工作，包括功能模块设计、存储设计、架构设计等，为后面的编码提供良好的基础保障。基于以上业务情况，按领域划分为七个小模块，每个模块中划分出相应实体、事件，通过软件简略画出关键数据实体-联系图（未包含所有实体），如下图所示：据第一篇需求分析的情况，我们已经识别出关键流程、主要业务模块以及模块中主要的业务实体、实体相关的事件。本案例完全可以采用单实体的模式开发，但为了模拟微服务开发的场景，所以这里按照微服务的设计方式

前面都是在会员与积分模块的业务功能，引领大家尝试了服务维护、配置中心、断路器、服务调用等常见的功能点。本博文节开始进入核心业务模块——停车计费，有两块数据曝光率特别高：进场前的可用车位数和计费规则，几乎每辆车都进出场都用到，这部分俗称为热数据：经常会用到。读关系库很明显不是最优解，引入缓存才是王道。这里仅讨论软件服务端的缓存，不涉及硬件部分。缓存作为互联网分布式开发两大杀器之一（另一个是消息队列），应用场景相当广泛，遇到高并发、高性能的案例，几乎都能看到缓存的身影。从应用与缓存的结合角度来区分可以分为本地缓

商场停车场景中，除了极少数功能不需要用户登陆外（如可用车位数），其余都是需要用户在会话状态下才能正常使用的功能。要在网关层实现统一的认证操作，本博文介绍网关层增加一个公共鉴权功能，来实现简单的认证，采用轻量级解决方案 JWT 的方式来完成。JSON Web Token（缩写 JWT）是比较流行的轻量级跨域认证解决方案，Tomcat 的 Session 方式不太适应分布式环境中，多实例多应用的场景。JWT 按一定规则生成并解析，无须存储，仅这一点要完爆 Session 的存储方式，更何况 Session 在多

对于分布式项目来说分布式锁是一个中高级工程师的必备技能。在停车系统中的会员办理月卡或签到累积的积分，可以在指定时间段内兑换商场优惠券，由于数量有限，时间有限，兑换操作相当集中，如果按正常流程处理的话，肯定会出现超兑的情况。比如只有 5000 张券，结果兑换出 8000 张，这对商场来说是一笔经济损失。为防止超兑，自然做法是按总量一个接一个兑换，至到兑换完，但多并发的情况下如何保证还一个一个兑换呢？自然而然就会想到锁上面来。提及锁，你脑海是不是出现了一堆关于锁的场景：死锁、互斥锁、乐观锁、悲观锁等等，本节介绍

不管是传统开发模式还是时下推崇的敏捷开发模式，都要从源头——业务需求开始着手，缺少了需求获取分析环节或本环节做的不够好，由此造成的错误会随着软件迭代的步伐，逐步被放大，近而造成巨大的损失。有时金钱成本尚可接受，但由此造成的时间成本、机会成本则是无法估量的。选取"商场停车业务"作为需求原型，有两个考量：一是场景熟知度比较高，业务理解上不存在很大障碍；二是能将我们所要表达的微服务特性融入进去，业务复杂度较低，便于上手开发，门槛太高反而不利于技术实践。相信大家经常去商场购物，不管你有没有停过车，商场的停车场不会是

微服务体系下，一个请求会调用多个服务，整个请求就会形成一个调用链，普通的日志输出是无法将整个体系串联起来，调用过程中某一个节点出现异常，定位排查难度系数增高，这种情况下就需要一个组件，来分析系统性能、展现调用链路，以便出现故障时快速定位并解决问题，由此 APM 工具闪亮登场。全称是Application Performance Management，关注于系统内部执行、系统间调用的性能瓶颈分析，与传统监控软件（比如 Zabbix）只提供一些零散的监控点和指标相比，即便告警也不知道问题是出在哪里。抛开商业工具

各个微服务模块基本已经就位，但系统运行的情况是怎么样，有没有办法查看的到呢？本篇就带你一起看看如何查看系统运行时的一些信息。帮助开发工程师排序问题，同时也是运维工程师提供数据的监控和服务的保护。本博文将介绍的微服务的监控功能设计。细心的小伙伴发现了，每个微服务的 pom 文件配置中都有如下的 jar 引用，这是 Spring Boot 提供的一系列额外特性组件以帮助你监控管理运行中的系统应用。除了需要引入对应 jar 包外，还需要指定的配置。由于默认只开放了 health、info 两个 API，其它

OpenFeign 完成了微服务间的调用，并且在多实例集群的情况下，通过调整负载策略很好应对并发调用。网络产品开发时，网络有时可能是不可用的，服务亦有可能是不可用的，当调用服务响应慢或不可用时，大量的请求积压，会成为压倒系统骆驼的最后一根稻草。它是分布式系统提供的一个低时延容错机制的基础组件，提供限流、服务降级、系统熔断保护、快速失败等多个维度来保障微服务的稳定性。Hystrix 也是 Netflix 套件的一部分。遗憾的是 1.5.18 版本之后进入了维护模式，官方提供了替代方案：resilience4j

微服务设计中的两个重要的项目：Spring Cloud 及Spring Cloud Alibaba，我们需要从理论角度作个整体性掌握，后续进入开发实战作好铺垫工作。为后续的微服务工具的选择和开发选择好的相关的准备。本博文将详细的介绍的Spring Cloud 及Spring Cloud Alibaba的微服务设计。它是由很多个组件共同组成的一套微服务技术体系解决方案，目前最新版本是 Hoxton，它的版本并不是我们常见的大版本、小版本的数字形式，Spring Cloud 的版本规划是按伦敦地铁站的名称先后顺

整个系统是多个应用一起构建，由于服务不会单独存在，服务开发团队必然与其他服务团队进行服务调用，暴露出对外接口势在必行。早期做开发的时候，大家习惯于以 word 或 excel 的形式，但弊端显而易见，一旦接口发生变动，文档需要同步更新，遗憾的是很多接口已经更新，但文档都没有跟上，相信你也有过痛苦的经历。本文带领你认识几款接口文档管理工具，并实现本案例实践中用到的在线接口文档管理。我们迫切需要一个接口文档工具，能实时与系统接口保持同步，无须额外付出成本（资金成本、时间成本）最好。这里介绍几个开源的 API 工

系统中的某些涉及多服务调用过程中多个数据库写入操作，可能涉及到数据的读写和多服务的数据分读写等……，通常spring中通过 @Transactional 注解进行事务控制，服务内尚未保证数据的完整性，跨服务后数据的完整性无法得到保护。利用分布式事务可以解决这类问题，本博文使用 Seata 组件来进行来确保跨服务场景下的数据完整性问题。先拿一个关键场景来铺垫下主题。车辆交费离场后，主要业务逻辑如下：涉及到三个服务间协作，数据分别写入三个存储库，是一个典型的分布式事务数据一致性问题。来看下正常场景的代码逻辑：

由于服务粒度的不同以及数据包装因端而异的差异需求，由于的系统采用的是的前后端分离的结构。调用端可以直接调用 BFF 层，由 BFF 层再将请求分发至不同微服务，进行数据组装。由于很多子服务都需要用户验证、权限验证、流量控制等，真的要在每个子服务中重复编写用户验证的逻辑吗？在大型微服务设计时候都在网关层统一处理这些共性需求。如果没有网关的情况下，服务调用面临的几个直接问题：现有系统的调用结构如下图所示：直接由前端发起调用，服务间的调用可以 由服务注册中心调配，但前端调用起来就没这么简单了，特别是后端服务以多实

想要成为一名优秀的架构师，但是你又不知道从哪里学习。下面给你分享几张学习的路径的图，按照这个知识整理好你自己的内容，不管是面试还是真的做项目都是十分有底气的。

如果你以往对 DDD 的了解并不深入，甚至是第一次接触，你一定会觉得 DDD 的术语非常多，且非常陌生，这些术语之间的关系都算是个“拦路虎”。搞懂这些之后呢，怎么应用它们，从何下手来设计领域模型等等这些问题又接踵而至。如果你对 DDD 有过研究，在学会怎么用之后，你可能还会反过来想：“我费了这么大劲儿去搞懂它，那它到底会让我的系统变成什么样呢？可以解决什么具体问题？是不是真有大家说得那么好？”。本博文就是讲解 DDD 的核心知识体系，具体包括：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对象、聚

进阶篇主要讲解领域事件、DDD 分层架构、几种常见的微服务架构模型以及中台设计思想等内容。如何通过领域事件实现微服务解耦？、怎样进行微服务分层设计？、如何实现层与层之间的服务协作？、通过几种微服务架构模型的对比分析，让你了解领域模型和微服务分层的作用和价值。中台设计的核心思想，和你探讨如何实现前中后台的协同和融合？如何利用 DDD 进行中台设计？

通过实战，让大家更加的理解和应用DDD在自己的项目中，实战如何用 DDD 设计思想构建企业级可复用的中台业务模型，了解事件风暴以及用事件风暴构建领域模型的过程。带你了解如何用 DDD 设计微服务代码模型，如何从领域模型完成微服务设计，建立领域模型与微服务代码模型的映射关系，如何完成微服务的架构演进等。

本博文主要介绍分布式系统知识脑图，帮助大家更好的快速的了解分布式系统相关知识。同时也是为大家在工作中应对分布式系统设计提供相关参考。

互联网发展到今天，用户数量越来越多，产生的数据规模也越来越大，应用系统必须支持高并发访问和海量数据处理的需求。对比集中式架构，分布式系统由于具有可扩展性，可以动态扩展服务和存储节点，使用廉价的机器构建高性能的服务，更适合如今的互联网业务。分布式系统技术已经成为微服务架构、大数据、云计算等技术领域的基石，在电商、互联网金融、支付等众多业务中，都离不开分布式技术的有效运用。一个分布式系统是一些独立的计算机集合，但是对这个系统的用户来说，系统就像一台计算机一样。本文主要介绍分布式的基础知识，以及分布式的理论基础和

摘要在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。如在美团点评的金融、支付、餐饮、酒店、猫眼电影等产品的系统中，数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求；特别一点的如订单、骑手、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。概括下来，那业务系统对ID号的要求有哪些呢？全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。 趋势递增：在MySQL InnoDB引擎中使用的是聚集

摘要本博文主要是的介绍分布式锁的原理和应用场景，分布式锁实现主要以Zookeeper（以下简称zk）、Redis、MySQL这三种为主。下面将分别对以上的分布式进行详细的说明。MySQL分布式锁Redis分布式锁Zookeeper分布式锁分布式锁总结参考博文...............

本博文详细介绍分布式事务原理与实战，熟悉多种分布式事务解决方案，帮助你的更好的应用在实践项目中。

本博文主要介绍分布式缓存原理与实现，帮助大家更好的学习分布式缓存原理和更好将缓存思想应用在自己的项目中。

本文主要介绍定时任务的基础和单体方式下定时任务方案的演化，以及常见的分布式任务方案和技术实现要点，帮助大家更好的学习理解分布式任务的思想，同时更好的在项目中应用分布式任务来完成部分系统设计工作。

通过了解一线互联网公司的架构的演进，以帮助自己在设计系统的时候参考。介绍淘宝从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。

根据第三方机构预统计，自2016年-2019年，我国零售信贷规模维持20%以上的高复合增长率，2017年中国零售信贷规模达到27万亿，到2019年，总规模超过37万亿。近年来互联网金融蓬勃发展，在借贷、保险、股权等领域涌现出一大批互联网与金融场景相结合的创新产品。同时作为互联网金融的子领域消费金融领域，在国家消费升级战略下，各大平台推出了如花呗、借呗，微粒贷等众多服务。互联网金融的架构有别于传统金融系统，互联网金融产品依托于互联网的众多技术特性，主要包括三大主要方面：在互联网浪潮的背景下，传统银行、金融行业

主要是介绍OpenHarmony 鸿蒙-面向全场景的分布式操作系统的新的技术点和一些新的概念，同时学习OpenHarmony 鸿蒙-面向全场景的分布式操作系统的具体的使用了开发。

在一体化架构中，单次请求的所有的耗时日志，都被记录在一台服务器上，而在微服务的场景下，单次请求可能跨越多个 RPC 服务，这就造成了，单次的请求的日志会分布在多个服务器上。于是，你给你的代码增加了大量的日志，来排查下单操作缓慢的问题。首先，A 服务在发起 RPC 请求服务 B 前，先从线程上下文中获取当前的 traceId 和 spanId，然后，依据上面的逻辑生成本次 RPC 调用的 spanId，再将 spanId 和 traceId 序列化后，装配到请求体中，发送给服务方 B。

简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中）， 后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令， 然后正常执行后面的业务逻辑。幂等更多使用的情况是第一次请求不知道结果（比如超时）或者失败的异常情况下，发起多次请求，目的是多次确认第一次请求成功，却不会因多次请求而出现多次的状态变化。

关于“负载均衡”的解释，百度词条里：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操作单元上进行执行，共同完成工作任务。负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

JWT简称JSON Web Token,也就是通过JSON形式作为Web应用中的令牌,用于在各方之间安全地将信息作为JSON对象传输。在数据传输过程中还可以完成数据加密、签名等相关处理。系统中采用JWT的技术来保证整个系统的数据访问的安全性性质。本博文将详细的介绍JWT鉴权服务设计，帮助大家更好的理解和学习JWT原理与使用。