12 | 架构现代化 ：微服务，你准备好了吗？
2022-05-06 姚琪琳
《遗留系统现代化实战》
课程介绍
讲述：姚琪琳
时长:大小11.39M
你好，我是姚琪琳。
上节课我们学习了架构现代化的新城区模式，今天我们继续聊新城区。
我们在自治气泡模式的基础上，通过事件拦截来实现数据同步，给气泡和遗留系统之间又加上 API 访问这个通信渠道。这时的自治气泡就和真正的微服务差不多了。
有了这种模式，在开发一个全新的需求时，你就可以将新需求实现在新的服务中，通过防腐层和遗留系统隔离，达到自治的目的。这样，新服务可以更好地演进，不受遗留系统的影响；遗留系统也不会因为新需求的增加而带来太多修改。
然而，单体真的不好吗？微服务一定是目标架构吗？
单体和微服务应该如何取舍？
这个问题众说纷纭，我先挑几个有代表性的咱...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
子夜枯灯2022-05-10编辑大大，我也来催稿啦。理论知识够丰富了，希望多加一些工具类的“术”。“道”+“蔬”才能降伏妖怪不是→_→编辑回复: 收到，其实老师后面会在合适位置推荐一些工具的，建议更多关注工具的使用条件、范围和思路，这样才不至于被工具束缚～
Kent2022-05-08学到这里才发现老师的课才出到一半。意犹未尽，十分期待接下来的内容。 我们项目从单体慢慢演化到微服务架构，刚好也是慢慢拆出来的。通知、推送、告警这些类似“基础设施能力”的服务，从各个业务中剥离出来。在公共代码库中放一个接口提供调用。普通业务无脑调用，十分方便。但是涉及到用户画像、订单库存这样交际复杂的业务，不太好拆，现在主服务里慢慢做代码重构大概来得更实际一些。作者回复: 感谢分享，你们做得很棒~
peter2022-05-07请教老师两个问题： Q1：文中的视频链接是youtube，无法访问，能否将视频放到能访问的地方？ Q2：我的系统有两个业务，一个业务一个微服务，但另外设计了一个“用户服务”，负责管理系统的使用者。系统是平台类，类似于电商，所以用户包括“买家（普通用户）”、“卖家（商户）”和系统管理员，共三类用户。“用户服务”负责管理这三类用户；在数据库层面上，一类用户一个表，共三个表。请问：这样设计合理吗？“用户服务”是“实体服务”吗？如果“用户服务”是“实体服务”，那么系统既有业务维度上的微服务，也有实体角度上的微服务，两个不同维度并列，微服务的划分维度就不统一了，这是个问题吗？？展开作者回复: Q2：用户服务不一定是实体服务，要看它要解决的是什么问题。如果要解决的是用户的级别、优惠策略等，就包含自己的业务逻辑，就不是实体服务；但如果只是CRUD，其他所有业务都要与其他业务相耦合，就离实体服务不远了。还要看你其他两个业务服务对用户服务的依赖程度，如果只是获取用户信息，就还好，如果自己的业务同时也依赖用户服务，就是分布式单体。
刘大明2022-05-06原来自己一直患有"微服务强迫症"，总是喜欢面向市场编程，市场说现在流行微服务就赶紧学习微服务，流行云原生就赶紧去看云原生，还不如怎么想好，把现有的系统怎么打磨好，提取更多的经验和方法，让自己平时的工作不受到遗留系统常见问题的困扰。作者回复: 其实什么流行就去学什么本身是没有问题的，什么流行就去用什么才有问题。
aoe2022-05-06原来要多读书，才能分辩出示例是好是坏（居然 Spring 和 微软的示例都有误导）！老师真强大！编辑回复: 感谢分享，一起学习进步哦～
- aoe2022-05-06目前我们的架构应该是：分布式单体。因为每次有新功能上线都有一堆服务要修改。
作者回复: 感谢分享。大多数声称使用了微服务的项目，都没法做到独立部署。
判伐2022-05-06更新太慢了，目前正在做遗留系统的改造，真想一口气看完😂编辑回复: 收到催稿心愿啦。理解你的期盼，我们正在马不停蹄地备稿、打磨、更新，每周更新三篇，其实内容还是很密集的，预计六月上旬就更完啦。希望对你有启发，也欢迎多多留言讨论。