- 博客(23)
- 收藏
- 关注
RSS订阅原创 事件顺序保护
为了保护事件顺序，需要根据性能要求选择合适的方案。如果性能不存在问题时，或者开始难以估算时，那么就用单个消息事件生产者和单个消费者，这样方案最简单，无需考虑并发问题。如果性能有问题，多数场景也是消费端，因此需要更多的消费者实例进程并发提高消费处理事件效率，但随之复杂性也显著提高。有的场景是为了高可用性，需要建立多个生产者实例和消费者实例，也让整个系统复杂性提高，不过为了可用性，还可以考虑用 k8s 这一类容器技术来保证各个服务实例的可用性。
2024-08-15 14:05:13
936
原创 分布式事务
saga 模式实现分为协同式和编排式，协同式需要多个参与微服务一起协同参与，编排式则由一个参与者主导完成各方参与者，显然编排式业务逻辑比较集中，容易把控维护，不像协同式那么分散，所以推荐编排式，编排式实现一般通过状态机框架协助实现，seata saga 主要也就是提供了状态机。saga 模式对业务的侵入性强，都需自定义实现，但灵活性高，适用面广，采用异步事件，性能也高，可用性也好，有些微服务架构方面书籍力主推荐 saga 来完成分布式事务。当 XA 模式不能满足的情况下，请考虑使用 saga 模式。
2024-08-15 13:42:55
348
原创 分布式同步锁
此时，第二个进程可以获得该锁，在 redis 添加了该 key，第一个进程现在把业务执行完，执行释放锁时，就会误把第二个进程加的锁释放掉，从而第二个进程没有锁住资源。为了避免这个误释放锁的问题，redis 设置 key 的 value 时 设置一个随机值，不同的进程的 value 值不同，当一个进程释放锁时，需要 key 和 value 和该进程加锁时值都相同，才能删除该 key，从而正确地释放锁，否则，value 不一致，表示该锁不是这个进程拥有的，无法释放。redis实现分布式锁的原理。
2024-08-15 12:27:02
443
原创 CQRS命令查询职责分离
总之，CQRS模式可以提高应用程序的可扩展性、可维护性和性能，但它的实现成本也很高，命令和查询的数据同步方案往往较为复杂，而且有的需要处理事件顺序和重复消息，因此，需要做好场景分析和成本估算后，谨慎选择 CQRS 的设计架构。
2024-08-15 12:16:42
460
原创 外部API模式
前后端分离后，后端需要提供 API 接口来支撑前端，常用 API 接口是 REST API。前端可能同时存在移动 web 端、pc web 端、app 端， 这些客户端展示样式和交互方式可能区别较大，因此他们所需的数据结构也有较大差距。后端在微服务分布式架构中有许多 API，哪些是暴露给前端外部 API，以及如何暴露，都需要仔细思考。
2024-08-15 12:04:24
706
原创 静态资源鉴权
API的鉴权通过鉴权框架就能完成，但像图片、文档、影音等文件就不适合了。这些文件访问时，一般通过web服务器就能直接访问这些静态资源，为了性能不会通过后端的业务程序来控制这些资源文件传输，也就没法对这些资源进行详细的访问控制。
2024-08-15 11:56:21
445
原创 认证和鉴权
认证鉴权是应用系统的基础需求，在微服务结构中服务分散，通常在 API 网关中进行身份验证和鉴权。当用户身份认证授权后，每次外部 API 的请求集中在网关中进行验证鉴权，不仅性能好，维护方便，还能让其余服务更加专注自己的业务。微服务中常用的认证鉴权解决方案为 jwt 、共享 session、 网关 oauth2 这三种。
2024-08-15 11:54:08
1580
原创 软件技术架构
每个服务的数据层是隔离的，都有各自的数据库，根据自己的特点选择不同数据库进行存储，服务只能访问自己的数据库，不能跨越其他服务的数据库，这样使得数据库的存储复杂度也比单体结构简单并易于维护。如果能够确定应用系统是在公有云上部署的，那么对绝大多数中小公司，在对技术选型时非核心部分，尽量选择云产品，例如云数据库、云消息中间件、云 Redis、云直播、云存储 等，这些维护简单，使用方便可靠，大大提高开发和运维效率，这些云产品成本往往比为此花费的人力成本要低，除非你的业务量非常大。
2024-08-15 10:58:13
629
原创 开发应用架构
应用架构是对业务架构的落实解决，业务架构还是停留在业务问题的分析，那么应用架构就是对业务问题的解决，它把业务功能转化成开发时对应的应用模块。
2024-08-15 10:51:14
1014
原创 软件业务架构
一说到架构设计，很多开发人员想到的就是数据库、中间件、微服务框架等各个技术框架和库，把这些组合就认为软件架构，还有很多号称架构工程师主要工作就套什么框架等，这些只能叫做框架师。架构的首要工作应该是业务架构，对确定的需求进行分析，分解成易于开发的业务模块。很多技术人员往往不怎么重视业务架构，常常对业务粗略分解，使得后续应用模块的划分不合理，导致高耦合、低内聚，使得整个系统交互异常复杂，难以开发和维护，这些问题是很难在技术架构层面解决的，所以必须重视业务架构。
2024-08-15 10:46:59
307
原创 开发文档分析
传统的瀑布模型的开发过程中的文档过重，需要大量时间编写各种文档，比如软件需求规格说明书， 概要设计，详细设计等等。现在的普遍采用的敏捷开发模式，而敏捷宣言中有工作软件胜过全面的文档，意图是最好把更多的注意力放在软件上，而不是把时间花在过于详细的前期文档上。因此，文档应该尽可能轻量化，只写必要的。
2024-08-15 10:44:46
266
原创 测试阶段的思考
很多公司的研发用测试出的缺陷数量来衡量测试人员和开发人员的绩效，测试出的缺陷多那么测试人员的绩效好，而开发人员所负责的模块缺陷数量多则绩效差，目标产生了冲突，因此会让两者产生对立。
2024-04-19 17:21:43
397
原创 编码阶段的思考
设计完成后，开发人员就开始编码了，测试人员写详细的测试用例 或基于 API 接口的自动化测试。编码涉及到 git 分支如何控制，是否要先写单元测试，是从上到下，还是从下到上的编码，如何前后端联调，代码是否要检视，如何检视，如何尽可能早地测试。
2024-04-19 17:19:54
1421
原创 设计阶段的思考
概要设计时不仅仅关心的是否能很好的实现本次精华后的需求，更多的还要关注是否领域模型的划分，设计的模块是否高内聚低耦合，保存足够的灵活性，是否已有部分需要重构，原先部分是否可以复用，技术选型是否项目总体的选型， 这样才能防止整个项目腐蚀，及时归还技术债务。敏捷式设计主要是原有的重构和当下的设计，这样所做的工作都是有效的，虽然敏捷设计会让原有的代码模块重构，但通过自动化测试，使得编码级的变更成本显著降低，再加上不断地重构优化代码结构，使得模块之间耦合足够低，代码保持整洁，这样也会使得重构成本不会增高。
2024-04-19 17:15:02
513
原创 需求分析的思考
需求评审过程中，如果出现大的争议，并且现场很难确定，并且影响后续大量的需求细节，可以先暂停会议，等这些问题解决了后再继续会议，一般的非关键性问题，现场也解决不了的，可以先记录下来，会后解决后再通知给大家。需求评审时，谨防临时添加更多的需求功能点，最好等这些必要基本功能上线后，根据用户的反馈再来完善，否则，不仅很容易白做，而且还引起返工。但这种用户故事列表，缺乏需求全局信息，在创建用户故事列表前，最好有一个总体需求分析，了解需求背景，要实现商业核心目标，参与的主要角色，使用的主要场景，核心的业务逻辑等等。
2024-04-19 17:05:08
472
原创 敏捷开发的思考
例如，我们要规划盖一个 100 层的摩天大楼，敏捷开发就是，先搭一层的基地盖一层楼交付给客户，根据客户的反馈，这一层楼再做哪些调整，要不要继续盖第二层，如果要盖第二层，开发团队先要做的是调整基地结构，使其能支持后续几层楼修建，然后再继续加盖。在实际当中，这些架构设计上的调整，已有功能的重构优化，客户和市场都不怎么愿意，毕竟不能直接产生业务上的价值，程序员也不愿意，因为眼下能运行就好，多一事不如少一事，但对项目开发又是至关重要的，否则，简单地堆砌代码，导致越来越臃肿，难以维护，最后会浑然倒塌。
2024-04-19 16:47:29
314
原创 开发团队外部沟通协作
向上管理向上管理是软件团队负责人的重要能力，有效的向上管理可以帮助你与上级建立互信关系，获得他们的支持和认可，更好地理解他们的期望和优先事项，从而更好地完成工作任务。此外，向上管理还可以帮助你在组织中获得更好的能见度和认可，为你的职业发展打下基础。我接下来根据一些场景，分享一些向上管理的理念。 领导安排的任务很难完成，如何处理？当你的上级领导给你一个任务，了解后觉得不可能完成，或风险很高，不要直接和领导说不可行或相关风险和困难，这样会让领导觉得工作态度不对，给你的任务是让你克服困难来完成
2024-04-11 17:35:06
1809
1
原创 软件团队日常管理
我分享软件团队的常规日常管理一些经验和思考。日报日报是一种日常工作记录，它可以帮助个人和团队有效地管理和跟踪工作进展，让上面各个层级领导了解每日工作情况，及时识别问题，也方便后面的工作汇总。日报主要内容是今日工作总结、明日工作计划和所需协助。日报编写要简要，不要超过10分钟，否则对写的人和看的人都是负担，有的日报写得很详细，导致写的人浪费大量精力在日报上，看的人也不能很快看到重点。今日总结主要写主要任务点和完成结果，以及所需协助。明日计划主要写出要做主要任务点及计划完成结果。这些完成结果最好以百
2024-04-11 17:32:07
757
1
原创 软件团队的人员管理
人员管理良好，是团队高效完成工作目标的基础。良好的团队文化和氛围，明确的团队目标和任务，确定的角色职责，有效的沟通机制，合理的绩效考核和激励，学习成长机会，有竞争力的薪资等，都有利于于团队的人员管理。有的在前面分享主题中已经说过，有的会在后面涉及，本次主要讨论和人员管理相关的方面：团队的人员层级划分，定期沟通，团建活动，薪酬，绩效考核，离职事宜，不合适人员辞退。人员层级划分团队人员的角色职责不同，工作能力不同，为了高效管理，管理者需要对团队成员进行层级划分。一般可以划分三个层级：核心人员，主要人员
2024-04-11 17:29:51
918
1
原创 软件工程师的招聘
要建设良好的开发团队，首先得招聘到合适的人才。合适的团队成员能够事半功倍，管理也会省心省力。本次要说的主要内容是关于普通软件开发工程师的招聘目标、面试过程和新人试用期阶段。
2024-04-11 17:27:28
1756
1
原创 软件开发团队管理的一些思考
好的管理，使得协作井然有序，相互促进，平衡各个方面的利益，从而更好的完成工作目标。因此，提高自身能力和更好完成工作的目标是一致的，但提升能力的说法有利于每个人自己，也更具有驱动力，也更符合人性规律。相反，如果总觉得没有意义，就会情绪低落，压抑，严重的就会患上抑郁症。判断依据这个观念有利于团队的绝大多数成员的利益，同时也对工作有利的，也能让大家普遍认可的，而且能够实现的。否则，就变成画大饼，现在很多人都很聪明，特别是当下年轻人更不信这一套，所以一定要真实可靠，只有能满足各方面的利益的观念，才能作为企业文化。
2024-04-11 17:22:35
409
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人