架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2041 人已学习
课程目录
已更新 15 讲 / 共 22 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想吃透架构?你得看看真实、接地气的架构案例
免费
概述篇 (1讲)
01 | 架构的本质:如何打造一个有序的系统?
业务架构篇 (9讲)
02 | 业务架构:作为开发,你真的了解业务吗?
03 | 可扩展架构:如何打造一个善变的柔性系统?
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
06 | 可扩展架构案例(三):你真的需要一个中台吗?
07 | 可复用架构:如何实现高层次的复用?
08 | 可复用架构案例(一):如何设计一个基础服务?
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
10 | 可复用架构案例(三):中台是如何炼成的?
技术架构篇 (4讲)
11 | 技术架构:作为开发,你真的了解系统吗?
12 | 高可用架构:如何让你的系统不掉链子?
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
架构实战案例解析
登录|注册

09 | 可复用架构案例(二):如何对现有系统做微服务改造?

王庆友 2020-03-11
你好,我是王庆友。在上一讲中,我以订单服务为例,和你一起讨论了如何从头开始,设计一个共享服务。今天我们再来聊一聊:如何对现有系统做微服务化改造
很多早期的互联网公司都有巨大的单体应用,底层的数据表集中放在一个数据库里,这些表加起来可能有几百张。对于这样的应用系统和数据库,我们往往需要对它们进行拆分,通过微服务化改造,保证系统能够不断地扩展和复用。
相比从头开始落地服务,对现有系统做微服务化改造,这会面临更多的挑战。
首先,应用和数据表紧密耦合在一起,代码模块和表是多对多的依赖关系。一个模块会访问多张表,多个模块也会对同一张表进行访问,而且由于表都在一个数据库里,开发人员往往会随意对表做关联,有时候甚至 Join 5~6 张表以上。这样,代码模块和表之间的关系是剪不断,理还乱,我们很难清晰地划分代码和数据表的边界,也就很难把它们封装成独立的微服务。
还有,系统现在已经在运行了,我们的改造不能影响业务的稳定性。那微服务落地后,现有的系统要怎么对接微服务,数据要怎么迁移,才能保证系统的平滑过渡呢?
所以,要想应对这些挑战,一方面,我们要保证比较合理的服务设计,才能达到优化系统架构的目的;另一方面,我们要做到整个过程对现有系统的影响比较小,才能达到系统改造顺利落地的目的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • Alex
    拆分最大的挑战还是服务间的多表查询问题。有些用冗余少量数据实现了,有的引入了汇总分析的大数据库。服务拆分后根据业务需要不得不冗余部分数据来换取性能,但是业务需要允许数据会存在短时间的不一致。比如原来设计表里只存了用户id 以前通过关联获取用户名,现在业务表可能就需要冗余用户名信息
    2020-03-11
    3
  • Jxin
    对标ddd的分层。

    1.业务应用对标接入层,是对应用(应用层)接口的调度,并提供外放的出入口。

    2.应用服务对标应用层,是对基础服务(领域层)的调度操作,通过整合和操作多个领域的聚合来提供新的功能。

    3.基础服务对标领域层,是整个架构的核心数据源头。其承接的逻辑应尽量限制在当前领域(数据库表)所涵盖的数据的范围内。以保证其独立性。

    总结:从这章来看,微服务的出现,实现了ddd项目垂直方向单独拆分成包的可能。虽然增加了调度成本,但提高了灵活扩展的能力和接口复用的空间。不知我的理解是否有误,还请栏主指点一二。

    提些问题:
    1.如果项目按这样拆分成独立包,那么单个包内部的分层又该如何设计?
    2.(1,2)这两块是否就不存在持久化数据的操作?
    3.如果不存在,那么应用服务策略相关的一些表又该存在何处?

    作者回复: 1.单个包内部还是按照单体应用进行分层,比如control-service-manager->dao
    2. 应用服务也有自己的数据库,比如一些配置信息,一些不属于基础服务的普通业务数据。

    2020-03-11
    2
  • Jeff.Smile
    不错的案例!
    2020-03-11
    1
  • 孙同学
    https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 学习总结更新;突然感觉自己是不是学早了,思考题好多都没经验可答
    2020-03-11
    1
  • 小洛
    具体落地库存微服务的时候,还要考虑数据迁移方案,做到平滑过度,还要考虑出故障了可以随时回滚,这应该属于技术架构去保证的了
    2020-03-16
  • 蓝天
    1,统一思想很重要,需要上层强有力的推动,否则很难

    2,我们现在的困境,业务方不愿配合,很多老代码换了好多批人了,想改调用方式可以,直接去业务方代码里自己改,改出问题你们负责,上线不能停机,业务不能受影响,有问题要能立即回退,(我们现在都是代码里加开关,但是数据库迁移不好弄)

    3,数据需要双向同步(面临随时可以切换回的问题),老师有什么好的建议或方法呢,感谢

    作者回复: 这样做功能调整确实比较痛苦,代码要两套,数据两份,要随时保证能够回去,系统越改越臃肿。

    可以先做好老板工作,然后在公司内部架构布道下,让业务开发方也意识到架构太旧,隐患很大,公司上下形成共识和合力。

    2020-03-13
  • Din
    曾经经历过一个单体系统的改造过程,主要遇到以下的问题:
    1. 系统改造短期是不会产生业务价值的,所以需要说服领导,让领导从长远利益考虑同意这件事
    2. 不能停下来完全做业务改造,同时还要兼顾新功能的开发
    3. 团队协作问题,需要大量的沟通和业务梳理
    4. 曾经的SQL关联改为接口调用,需要考虑性能问题,需要用冗余数据或批量接口来解决
    5. 我们是从基础服务开始(短信,支付,合同等等),因为业务简单,对接方便,把整个流程跑一边后才改造业务服务

    作者回复: 嗯,这些都是比较典型的问题,和本文描述的非常类似。
    通过老系统改造,相信你也学到很多宝贵的经验。

    2020-03-11
  • tt
    对于老系统,先做数据的拆分,将业务子域的数据从全集数据中拆分出来,然后通过服务的形式把数据暴露出去,形成微服务。


    在选择将哪个业务子域的数据拆分出来时选择的标准是收益成本比较高,达成的目标是在数据不越界的前提下控制好粒度。(这一点符合之前课里讲的提高复用性时的原则:服务覆盖全部业务域的数据,这样基础服务之间可以做到互相正交)

    通过这一课,联想到服务的可复用性提高了,那对它的上层服务来说,只要接入一个服务节点就可以了,由于被接入的服务封装了业务域内的多个数据实体成为一个数据模型(就是抽象的层次更高了),从而将系统内实体的关系从多对多改成“多对一”。这样,上层服务要处理的细节减少,提高了业务的可扩展性。下层的服务抽象水平更高,可以被更多的上层业务复用,它本身从技术上也更容易水平扩展了。

    自己所在的公司没有巨大的单体业务,但却有很多和规模不大的小单体,现在需要通过一个渠道将它们的能力暴露给外部,附带的需要新增用户管理、商户管理的任务即相关的鉴权授权限流需求。所以听老师的课特别有感触。

    一号店库存服务的改造过程是 上层业务-业务内嵌库存SQL-包含库存表的单一大库 变为 上层业务-库存服务-包含库存表的单一大库 进一步变为 上层业务-库存服务-库存独立数据库的过程。感觉就是从贫血模型变为充血模型,再把后者独立成服务的过程。

    之前和同事讨论的时候,对于数据库是否和服务一起独立想法不一致,但是在接口设计良好的前提下,数据是否独立是可以比较平滑地切换的(但是如果数据库不独立,无法阻止开发人员随意的存取数据表导致的架构恶化)。

    作者回复: 赞一个,很好的分享,把文章和实际做过的东西很好地结合起来,大家感触更深。
    对于服务来说,应该是代码和数据一体的,不然,表访问会不断越界,这相当于,部分业务规则游离于服务外部,违背服务完整性原则。

    2020-03-11
收起评论
8
返回
顶部