- 博客(23)
- 收藏
- 关注
RSS订阅原创 事件顺序保护
为了保护事件顺序，需要根据性能要求选择合适的方案。如果性能不存在问题时，或者开始难以估算时，那么就用单个消息事件生产者和单个消费者，这样方案最简单，无需考虑并发问题。如果性能有问题，多数场景也是消费端，因此需要更多的消费者实例进程并发提高消费处理事件效率，但随之复杂性也显著提高。有的场景是为了高可用性，需要建立多个生产者实例和消费者实例，也让整个系统复杂性提高，不过为了可用性，还可以考虑用 k8s 这一类容器技术来保证各个服务实例的可用性。
2024-08-15 14:05:13
1044
原创 分布式事务
saga 模式实现分为协同式和编排式，协同式需要多个参与微服务一起协同参与，编排式则由一个参与者主导完成各方参与者，显然编排式业务逻辑比较集中，容易把控维护，不像协同式那么分散，所以推荐编排式，编排式实现一般通过状态机框架协助实现，seata saga 主要也就是提供了状态机。saga 模式对业务的侵入性强，都需自定义实现，但灵活性高，适用面广，采用异步事件，性能也高，可用性也好，有些微服务架构方面书籍力主推荐 saga 来完成分布式事务。当 XA 模式不能满足的情况下，请考虑使用 saga 模式。
2024-08-15 13:42:55
398
原创 分布式同步锁
此时，第二个进程可以获得该锁，在 redis 添加了该 key，第一个进程现在把业务执行完，执行释放锁时，就会误把第二个进程加的锁释放掉，从而第二个进程没有锁住资源。为了避免这个误释放锁的问题，redis 设置 key 的 value 时 设置一个随机值，不同的进程的 value 值不同，当一个进程释放锁时，需要 key 和 value 和该进程加锁时值都相同，才能删除该 key，从而正确地释放锁，否则，value 不一致，表示该锁不是这个进程拥有的，无法释放。redis实现分布式锁的原理。
2024-08-15 12:27:02
529
原创 CQRS命令查询职责分离
摘要：CQRS（命令查询职责分离）模式通过将数据修改（命令）和读取（查询）操作分离，使用独立的数据模型和存储方案来应对复杂业务场景。命令操作通常采用关系型数据库保证事务一致性，查询操作则可采用NoSQL或缓存提升性能，二者通过异步消息实现数据同步。该模式适合业务逻辑复杂、读写模型差异大的系统，能提高可维护性和扩展性，但实现成本较高。在简单CRUD场景或业务规则简单时则不适用，需根据实际需求权衡采用。
2024-08-15 12:16:42
568
原创 外部API模式
摘要：本文对比分析了前后端分离架构中的两种API模式。客户端组合API模式虽能减轻服务端负担，但存在多次请求、前端复杂度增加、API兼容性差等问题。推荐采用API网关模式，通过网关统一处理API组合、鉴权、限流等功能，具有三大优势：1)减少网络请求提升响应速度；2)稳定接口隔离后端变化；3)让客户端专注展示层。同时指出两个重要原则：1)计算密集型API可保留客户端组合；2)组合API中最多只能包含一个写操作，避免分布式事务问题。实践表明，API网关模式更适合大多数业务场景。
2024-08-15 12:04:24
816
原创 静态资源鉴权
摘要：静态资源鉴权有多种方案。后端传输资源适合严格访问控制但性能要求不高的场景；临时访问URL适合性能要求高但控制较宽松的情况；回调鉴权+加密URL则适用于需要精细控制、高性能且使用CDN的场景。选择方案时应根据业务需求平衡性能与安全性。
2024-08-15 11:56:21
608
原创 认证和鉴权
认证鉴权是应用系统的基础需求，在微服务结构中服务分散，通常在 API 网关中进行身份验证和鉴权。当用户身份认证授权后，每次外部 API 的请求集中在网关中进行验证鉴权，不仅性能好，维护方便，还能让其余服务更加专注自己的业务。微服务中常用的认证鉴权解决方案为 jwt 、共享 session、 网关 oauth2 这三种。
2024-08-15 11:54:08
2215
原创 软件技术架构
每个服务的数据层是隔离的，都有各自的数据库，根据自己的特点选择不同数据库进行存储，服务只能访问自己的数据库，不能跨越其他服务的数据库，这样使得数据库的存储复杂度也比单体结构简单并易于维护。如果能够确定应用系统是在公有云上部署的，那么对绝大多数中小公司，在对技术选型时非核心部分，尽量选择云产品，例如云数据库、云消息中间件、云 Redis、云直播、云存储 等，这些维护简单，使用方便可靠，大大提高开发和运维效率，这些云产品成本往往比为此花费的人力成本要低，除非你的业务量非常大。
2024-08-15 10:58:13
751
原创 开发应用架构
应用架构是对业务架构的落实解决，业务架构还是停留在业务问题的分析，那么应用架构就是对业务问题的解决，它把业务功能转化成开发时对应的应用模块。
2024-08-15 10:51:14
1120
原创 软件业务架构
本文探讨了架构设计中业务架构的核心地位及其实践方法。文章指出，真正的架构设计应首先关注业务架构而非技术组件，强调业务分解为高内聚、低耦合模块的重要性。重点介绍了领域驱动设计(DDD)方法，通过将业务划分为核心域、通用域和支撑域来实现模块化设计。文章还讨论了子域粒度的考量原则，以及在敏捷开发中业务架构需要持续调整的特点。最后指出业务架构完成后需转化为具体的技术应用架构，包括技术选型和系统接口设计等环节，以确保业务需求的实现。
2024-08-15 10:46:59
382
原创 开发文档分析
传统的瀑布模型的开发过程中的文档过重，需要大量时间编写各种文档，比如软件需求规格说明书， 概要设计，详细设计等等。现在的普遍采用的敏捷开发模式，而敏捷宣言中有工作软件胜过全面的文档，意图是最好把更多的注意力放在软件上，而不是把时间花在过于详细的前期文档上。因此，文档应该尽可能轻量化，只写必要的。
2024-08-15 10:44:46
325
原创 测试阶段的思考
本文概述了软件测试流程与开发协作机制。测试流程包括安装测试、自动化/手动测试结合、缺陷处理及非功能性测试，强调缺陷提交需规范详细。缺陷处理遵循优先级原则，遗留问题需团队讨论决定。针对测试与开发在缺陷数量考核上的矛盾，建议以用户实际反馈为绩效标准，将发布后问题责任共担。文章指出质量保障需贯穿需求、设计、开发、测试全流程，测试仅是最后防线。最终目标是实现各环节高质量交付，确保项目整体质量。
2024-04-19 17:21:43
439
原创 编码阶段的思考
设计完成后，开发人员就开始编码了，测试人员写详细的测试用例 或基于 API 接口的自动化测试。编码涉及到 git 分支如何控制，是否要先写单元测试，是从上到下，还是从下到上的编码，如何前后端联调，代码是否要检视，如何检视，如何尽可能早地测试。
2024-04-19 17:19:54
1494
原创 设计阶段的思考
概要设计时不仅仅关心的是否能很好的实现本次精华后的需求，更多的还要关注是否领域模型的划分，设计的模块是否高内聚低耦合，保存足够的灵活性，是否已有部分需要重构，原先部分是否可以复用，技术选型是否项目总体的选型， 这样才能防止整个项目腐蚀，及时归还技术债务。敏捷式设计主要是原有的重构和当下的设计，这样所做的工作都是有效的，虽然敏捷设计会让原有的代码模块重构，但通过自动化测试，使得编码级的变更成本显著降低，再加上不断地重构优化代码结构，使得模块之间耦合足够低，代码保持整洁，这样也会使得重构成本不会增高。
2024-04-19 17:15:02
597
原创 需求分析的思考
敏捷开发中的用户故事与需求管理流程摘要： 敏捷开发采用用户故事替代传统需求文档，以简洁描述提升沟通效率。需求通过用户故事地图（Epic→Feature→UserStory）分层拆解，按商业价值等维度排序。迭代开发前需进行需求精细化：产品经理筛选独立故事，通过原型图/思维导图输出需求，复杂流程辅以UML图。需求评审会议要求全员预读文档，聚焦功能设计而非实现细节，实时修改并控制变更。任务分解为4-16小时工作单元，鼓励主动领取。团队参与需求精化可采取"主导+补充"模式平衡效率与质量。整个流程
2024-04-19 17:05:08
565
原创 敏捷开发的思考
例如，我们要规划盖一个 100 层的摩天大楼，敏捷开发就是，先搭一层的基地盖一层楼交付给客户，根据客户的反馈，这一层楼再做哪些调整，要不要继续盖第二层，如果要盖第二层，开发团队先要做的是调整基地结构，使其能支持后续几层楼修建，然后再继续加盖。在实际当中，这些架构设计上的调整，已有功能的重构优化，客户和市场都不怎么愿意，毕竟不能直接产生业务上的价值，程序员也不愿意，因为眼下能运行就好，多一事不如少一事，但对项目开发又是至关重要的，否则，简单地堆砌代码，导致越来越臃肿，难以维护，最后会浑然倒塌。
2024-04-19 16:47:29
381
原创 开发团队外部沟通协作
向上管理向上管理是软件团队负责人的重要能力，有效的向上管理可以帮助你与上级建立互信关系，获得他们的支持和认可，更好地理解他们的期望和优先事项，从而更好地完成工作任务。此外，向上管理还可以帮助你在组织中获得更好的能见度和认可，为你的职业发展打下基础。我接下来根据一些场景，分享一些向上管理的理念。 领导安排的任务很难完成，如何处理？当你的上级领导给你一个任务，了解后觉得不可能完成，或风险很高，不要直接和领导说不可行或相关风险和困难，这样会让领导觉得工作态度不对，给你的任务是让你克服困难来完成
2024-04-11 17:35:06
2174
1
原创 软件团队日常管理
我分享软件团队的常规日常管理一些经验和思考。日报日报是一种日常工作记录，它可以帮助个人和团队有效地管理和跟踪工作进展，让上面各个层级领导了解每日工作情况，及时识别问题，也方便后面的工作汇总。日报主要内容是今日工作总结、明日工作计划和所需协助。日报编写要简要，不要超过10分钟，否则对写的人和看的人都是负担，有的日报写得很详细，导致写的人浪费大量精力在日报上，看的人也不能很快看到重点。今日总结主要写主要任务点和完成结果，以及所需协助。明日计划主要写出要做主要任务点及计划完成结果。这些完成结果最好以百
2024-04-11 17:32:07
968
1
原创 软件团队的人员管理
人员管理良好，是团队高效完成工作目标的基础。良好的团队文化和氛围，明确的团队目标和任务，确定的角色职责，有效的沟通机制，合理的绩效考核和激励，学习成长机会，有竞争力的薪资等，都有利于于团队的人员管理。有的在前面分享主题中已经说过，有的会在后面涉及，本次主要讨论和人员管理相关的方面：团队的人员层级划分，定期沟通，团建活动，薪酬，绩效考核，离职事宜，不合适人员辞退。人员层级划分团队人员的角色职责不同，工作能力不同，为了高效管理，管理者需要对团队成员进行层级划分。一般可以划分三个层级：核心人员，主要人员
2024-04-11 17:29:51
1117
1
原创 软件工程师的招聘
本文详细阐述了软件开发团队招聘的关键环节。文章从招聘目标(初级、中级、高级工程师的选择)开始，探讨了学历背景、工作经验类型的取舍，强调应根据项目特点选择合适人才。重点介绍了机试+面谈的面试流程，包括项目经验、协作能力、技术深度等考察要点。最后详细说明了试用期管理策略，包括业务熟悉、技术考察、逐步独立三个阶段，强调导师制与持续沟通的重要性。文章为技术团队招聘提供了系统性的实践指导，特别适合中小企业的招聘参考。
2024-04-11 17:27:28
1997
1
原创 软件开发团队管理的一些思考
本文总结了软件开发团队管理的核心经验。作者提出管理应遵循人性规律而非对抗，强调建立积极向上的团队文化比单纯奖惩更有效。针对软件开发团队，建议通过分享会、技术培训等方式将能力提升的文化落到实处。同时指出流程管理应灵活调整，避免形式主义。文章认为优秀的管理需要顺应人性、协调各方，通过"遵循规律+团队文化+奖惩机制+流程优化"的综合方案，才能真正提升团队效能。这些理念来自作者十年管理实践的深入思考。
2024-04-11 17:22:35
485
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人