09 | 可复用架构案例（二）：如何对现有系统做微服务改造？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
1号店的库存服务化改造案例为读者提供了深入了解微服务化改造过程和挑战的机会。文章首先介绍了对现有系统进行微服务化改造所面临的挑战，包括紧密耦合的应用和数据表以及对系统运行稳定性的影响。随后，通过1号店的库存服务化改造案例，详细讲解了准备阶段和实施阶段的具体步骤，包括圈表、SQL收集和拆分、构建库存微服务、接入库存微服务以及数据库独立等关键步骤。在整个改造过程中，强调了不同团队之间的配合和沟通的重要性，以及技术层面和项目推进角度的考量。最后，通过1号店的总体系统架构图展示了通过微服务化改造，系统如何提升了业务的复用性和系统的稳定性。整个案例展示了微服务化改造的具体过程和挑战，以及如何应对这些挑战进行系统改造。文章通过实例详细阐述了微服务化改造的具体步骤和挑战，为读者提供了宝贵的实践经验和思路。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(22)
- 最新
- 精选
tt对于老系统，先做数据的拆分，将业务子域的数据从全集数据中拆分出来，然后通过服务的形式把数据暴露出去，形成微服务。 在选择将哪个业务子域的数据拆分出来时选择的标准是收益成本比较高，达成的目标是在数据不越界的前提下控制好粒度。（这一点符合之前课里讲的提高复用性时的原则：服务覆盖全部业务域的数据，这样基础服务之间可以做到互相正交） 通过这一课，联想到服务的可复用性提高了，那对它的上层服务来说，只要接入一个服务节点就可以了，由于被接入的服务封装了业务域内的多个数据实体成为一个数据模型（就是抽象的层次更高了），从而将系统内实体的关系从多对多改成“多对一”。这样，上层服务要处理的细节减少，提高了业务的可扩展性。下层的服务抽象水平更高，可以被更多的上层业务复用，它本身从技术上也更容易水平扩展了。 自己所在的公司没有巨大的单体业务，但却有很多和规模不大的小单体，现在需要通过一个渠道将它们的能力暴露给外部，附带的需要新增用户管理、商户管理的任务即相关的鉴权授权限流需求。所以听老师的课特别有感触。 一号店库存服务的改造过程是 上层业务-业务内嵌库存SQL-包含库存表的单一大库 变为 上层业务-库存服务-包含库存表的单一大库 进一步变为 上层业务-库存服务-库存独立数据库的过程。感觉就是从贫血模型变为充血模型，再把后者独立成服务的过程。 之前和同事讨论的时候，对于数据库是否和服务一起独立想法不一致，但是在接口设计良好的前提下，数据是否独立是可以比较平滑地切换的（但是如果数据库不独立，无法阻止开发人员随意的存取数据表导致的架构恶化）。作者回复: 赞一个，很好的分享，把文章和实际做过的东西很好地结合起来，大家感触更深。 对于服务来说，应该是代码和数据一体的，不然，表访问会不断越界，这相当于，部分业务规则游离于服务外部，违背服务完整性原则。
2020-03-1112
Din曾经经历过一个单体系统的改造过程，主要遇到以下的问题： 1. 系统改造短期是不会产生业务价值的，所以需要说服领导，让领导从长远利益考虑同意这件事 2. 不能停下来完全做业务改造，同时还要兼顾新功能的开发 3. 团队协作问题，需要大量的沟通和业务梳理 4. 曾经的SQL关联改为接口调用，需要考虑性能问题，需要用冗余数据或批量接口来解决 5. 我们是从基础服务开始（短信，支付，合同等等），因为业务简单，对接方便，把整个流程跑一边后才改造业务服务作者回复: 嗯，这些都是比较典型的问题，和本文描述的非常类似。 通过老系统改造，相信你也学到很多宝贵的经验。
2020-03-1129
Jxin
对标ddd的分层。 1.业务应用对标接入层，是对应用（应用层）接口的调度，并提供外放的出入口。 2.应用服务对标应用层，是对基础服务（领域层）的调度操作，通过整合和操作多个领域的聚合来提供新的功能。 3.基础服务对标领域层，是整个架构的核心数据源头。其承接的逻辑应尽量限制在当前领域（数据库表）所涵盖的数据的范围内。以保证其独立性。 总结：从这章来看，微服务的出现，实现了ddd项目垂直方向单独拆分成包的可能。虽然增加了调度成本，但提高了灵活扩展的能力和接口复用的空间。不知我的理解是否有误，还请栏主指点一二。 提些问题： 1.如果项目按这样拆分成独立包，那么单个包内部的分层又该如何设计？ 2.（1,2）这两块是否就不存在持久化数据的操作？ 3.如果不存在，那么应用服务策略相关的一些表又该存在何处？作者回复: 1.单个包内部还是按照单体应用进行分层，比如control-service-manager->dao 2. 应用服务也有自己的数据库，比如一些配置信息，一些不属于基础服务的普通业务数据。
2020-03-115
brant老师您好，我想请问一下您理解的库存服务的本质是什么，它里面管理的是什么库存，仓库实物库存还是商家销售库存，商家实物库存还是其他库存？您是怎么理解实物库存的，它的承载的价值意义是啥？作者回复: 库存系统一般有两套，一套是仓库管理用的，针对的是商品的物理库存，也就是实际数量，还包括商品实际存储位置的管理。 还有一套库存系统管理前台的销售库存，针对商品的可售数量，下单时使用，它不关心商品存储位置(库位)，我们平常说的库存服务指的是这个销售库存。根据销售模式不同，销售库存分细分为 商品实物库存，虚拟库存（商品还没采购就先预售），冻结库存（订单结束后才释放）等，玩法很多。 两套库存之间的关系是物理库库存在商品上架后就变成销售里的实物库存。
2020-04-084
暮色晨春基础服务以上的应用服务，是否就是属于应用场景梳理后形成的服务模型？作者回复: 属于应用场景梳理后形成的聚合服务，一般来说，基础服务属于正在意义上的服务，针对具体业务领，封装性和重用性都比较好
2021-06-013
果然爸爸那些跨表join的场景特别多。sql拆开，性能会有一些问题，还有分别查询，组合起来分页非常麻烦。不知道老师有没有什么好办法。作者回复: 跨表join场景很多一定程度上服务和表划分有些问题，服务和数据耦合过紧。有些查询确实需要跨表，可以先从核心服务里查好数据并分页，然后从其他服务以批量的方式补充数据。还有可以通过额外的数据服务，做好跨服务的聚合，来满足这方面的功能。
2020-05-163
冬天的树1号店业务服务的订单管理和基础服务的订单服务是啥关系啊？应用服务的下单是聚合服务么？如果下单服务，那觉得应该是下单直接对接系统就可以了吧作者回复: 订单管理是一系列订单相关功能的范称，下单服务是聚合服务，它会调用基础服务的订单服务，商品服务，库存服务，用户服务等。
2021-07-252
金智老师，您好，我有一些问题咨询一下您。1.最后一张图当中：基础服务当中有支付服务，应用服务当中有Payment，业务应用当中有结算中心，这些好像都是和服务相关的，这个有什么区别？基础服务当中的支付服务和在应用服务当中的Payment的确保是在Payment当中有和其他基础服务的聚合的话，那业务应用当中的结算中心有和Payment有什么却别？2.基础服务、应用服务、业务应用这三层是每一层当中当中的一个框框就是一个微服务？3.业务不是特别的多，基础服务的用户中心的api很少？这个还有没有必要拆成单独的微服务？4.在聚合层一般怎么去拆分？是根据业务拆分？一个业务一个微服务？多谢您了。作者回复: 1. 结算中心属于财务范畴，涵盖的功能比payment要复杂很多。 2. 每一层的一个框框是一个独立的应用或者说服务 3. 用户中心虽然目前api很少，还是建议拆成一个独立服务，一方面它的定义较大，后续很可能会不断增加api；另一方面，它处于底层，和其他放一起，会模糊依赖关系。 4. 聚合层和业务场景对应，按照业务场景拆比较好，比如C端的服务方一起，B端的业务放一起
2020-11-162- Geek_0e5f26老师 请教一个问题 1 号店的总体系统架构图中 业务应用和应用服务 这两个层都是做什么的，他们依据什么划分的？
作者回复: 业务应用就是具体的应用，比如首页，详情页都是用户可以直接感知到的内容，应用服务是把业务应用里的核心逻辑拿出来，形成服务，但这个服务面向具体的应用场景，不像基础服务可以让不同业务场景共享。
2020-09-252 - Robin康F我们正在对老系统进行重构，老系统功能比较，新系统设计既要兼顾原来的功能，还要对一些不合理的地方进行改造，同时加入新的功能，还要对未来3到5年做展望设计，导致开发过程很多意外情况，老师对这种大而复杂的改造有什么好建议吗
作者回复: 先按照理想的设计，再根据实际情况折中落地，改良和革命结合。比如比较独立的可以剥离出来，外部系统依赖它的逐步接入，比较固定不变的可以在原来基础上优化。要保证循序渐进和可控，能达到大部分的改造效果就可以。
2020-04-222
