精华内容
下载资源
问答
  • 哪些系统要微服务改造
    2022-06-21 20:27:45

    服务划分规则

    基于业务逻辑

    将系统中的业务按照职责范围进行识别,职责相同的划分为一个单独的服务。

    基于稳定性

    将系统中的业务模块按照稳定性进行排序。稳定的、不经常修改的划分一块;将不稳定的,经常修改的划分为一个独立服务。比如日志服务、监控服务都是相对稳定的服务,可以归到一起。

    基于可靠性

    同样,将系统中的业务模块按照可靠性进行排序。对可靠性要求比较高的核心模块归在一起,对可靠性要求不高的非核心模块归在一块。 这种拆分的高明可以很好的规避因为一颗老鼠屎坏了一锅粥的单体弊端,同时将来要做高可用方案也能很好的节省机器或带宽的成本。

    基于高性能

    同上,将系统中的业务模块按照对性能的要求进行优先级排序。把对性能要求较高的模块独立成一个服务,对性能要求不高的放在一起。比如全文搜索,商品查询和分类,秒杀就属于高性能的核心模块。

    人员配置

    按照三个人一个服务来配置,但是这不代表三个人只做这一个服务,而是一个人负责这个服务的主要核心工作,还有别的项目的基础项目这样的模式,这样如果某个服务的某个人突然有事2,另外稍微知道这个服务的人可以顶上

    更多相关内容
  • 本文来自于技术琐话,本章介绍了遗留系统的特点、改造策略和场景,并结合一个实战案例进行了讲解,希望对您的学习有所帮助。在传统企业甚至互联网企业中往往存在大量的遗留系统,这些遗留系统大多都能够正常工作,有...
  • 应用系统迁移上云和微服务改造经验分享-最佳实践.docx
  • 本文来自于weixin,本章从对遗留系统进行微服务改造的原则要求出发,探讨如何使用 Dubbo框架实现单体系统向微服务的迁移。Themicroservicesstyleofarchitecture highlightsrisingabstractionsinthedeveloperworld ...
  • 业务系统是任何一个用户产品的必须组成,充当着一个门面的角色,用户的输入就是这个系统需要维护的,数据存取是整个系统的核心。例如,广告业务系统的输入是广告主的投放约束、定向条件,微博业务系统的输入是短文字...
  • 可视化的遗留系统微服务改造(54页).pdf
  • 对于这样的应用系统和数据库,我们往往需要对它们进行拆分,通过微服务改造,保证系统能够不断地扩展和复用。   相比从头开始落地服务,对现有系统微服务改造,这会面临更多的挑战。   首先,应用和数据表...

      很多早期的互联网公司都有巨大的单体应用,底层的数据表集中放在一个数据库里,这些表加起来可能有几百张。对于这样的应用系统和数据库,我们往往需要对它们进行拆分,通过微服务化改造,保证系统能够不断地扩展和复用。
      相比从头开始落地服务,对现有系统做微服务化改造,这会面临更多的挑战。
      首先,应用和数据表紧密耦合在一起,代码模块和表是多对多的依赖关系。一个模块会访问多张表,多个模块也会对同一张表进行访问,而且由于表都在一个数据库里,开发人员往往会随意对表做关联,有时候甚至 Join 5~6 张表以上。这样,代码模块和表之间的关系是剪不断,理还乱,我们很难清晰地划分代码和数据表的边界,也就很难把它们封装成独立的微服务。
      还有,系统现在已经在运行了,我们的改造不能影响业务的稳定性。那微服务落地后,现有的系统要怎么对接微服务,数据要怎么迁移,才能保证系统的平滑过渡呢?
      所以,要想应对这些挑战,一方面,我们要保证比较合理的服务设计,才能达到优化系统架构的目的;另一方面,我们要做到整个过程对现有系统的影响比较小,才能达到系统改造顺利落地的目的。
      接下来,我就以 1 号店库存服务化改造为例,让你深入理解,我们是如何把库存相关的功能和数据表,从现有系统里剥离出来,最终构建独立的库存服务,并实现和业务系统平滑对接的。

    改造背景和目标

      我们先来看下这次架构改造的背景和目标。
      1 号店作为一个网上超市,售卖的商品种类有数十万个,包括 1 号店自营和第三方商家的商品。由于历史原因,所有商品相关的表都存在产品库里面,这里面有产品的表(产品、分类、品牌、组合关系、属性等)、商品 SKU 的表、商家和供应商的表、库存和价格的表等等,这些表加起来,数量超过了上百张。
      我们知道,商品是电商业务的核心,几乎所有的前后台系统都需要访问这个产品库,而这些系统的开发人员,早期的时候,只关心如何实现业务功能,对这些表的访问是怎么方便怎么来,有些 SQL 语句会对大量的表做 Join 关联。所以说,虽然系统是类似分布式的,但数据库是集中式的,如下图所示:
    在这里插入图片描述
      这样的方式,就给系统的维护带来了一系列的问题。
      从应用方面来说,各个系统功能重复建设,比如很多系统都会直接访问库存相关的表,类似的库存逻辑散布在很多地方;另外,如果修改了库存表的某个字段,这些系统同时会受影响,正所谓牵一发而动全身。
      从数据库方面来说,数据库的可用性是比较差的,如果某个系统有慢查询,它就很可能拖垮整个产品数据库,导致它不可用;还有,这么多系统同时访问产品库,数据库的连接数也经常不够用。
      所以,我们这次架构改造的目标,首先是对这个大数据库按照业务维度进行垂直拆分,比如分成产品数据库、库存数据库、价格数据库等等;然后基于这些拆分后的库,构建微服务,以接口的方式来支持数据库表的访问;最后将各个业务系统统一接入微服务,最终完成整个商品体系的微服务化改造。

    微服务改造过程

      你可以看到,这里涉及了多个微服务,如果同时进行服务化改造的话,牵扯太大,很难落地。于是,我们选择从库存微服务开始。一方面,库存的业务很重要,库存的规则也比较复杂,如果我们能够对库存逻辑进行优化,这会带来明显的业务价值;另一方面,电商的库存概念相对独立,涉及的表也比较少,我们可以相对容易地把它从现有体系中剥离出来。
      整个改造过程,从确定库存相关的表开始,到最后把库存表从产品库迁移出来,落到单独的库存数据库为止,一共分为两个阶段,每个阶段包含了 3 个步骤,具体如下图所示:
    在这里插入图片描述

    • 准备阶段:这个阶段为微服务改造做好前期的准备工作,具体步骤包括了圈表、收集SQL 和 SQL 拆分。
    • 实施阶段:这个阶段实际落地微服务,具体步骤包括微服务开发、服务接入和数据库独立
        通过这些良好定义的步骤,我们就很好地保证了整个库存微服务改造的有序和可控。接下来,我就具体说明下改造的各个步骤,包括哪些人负责哪些事情、具体的挑战在什么地方,这样,你可以深入地理解整个改造过程。

    准备阶段

      准备阶段的第一步,就是圈表。产品数据库有 100 多张表,圈表就是用来确定库存微服务
      具体包含哪些表,也就是确定服务的数据模型。在确定了表以后,库存微服务就负责这些表的访问,当然,库存微服务也不会访问其它的表,而业务系统后续将通过库存微服务的接口,实现对这些表的访问。
      圈表是微服务改造中比较有挑战性的地方,它实际上对应了服务的边界划分。只是针对老系统做服务化改造的时候,我们更多的是从数据库表的角度来考虑划分,这样更好落地。
      针对库存微服务来说,我们要求圈定的表,一方面要满足所有的库存访问需求,这些表之间关系紧密,和其它的表关联不大;另一方面,这些表的数量不能太多,一般不超过十几张。
      这样,我们既容易拆分数据库,又能控制服务的粒度,保证功能聚焦。
      在这个例子中,由于库存的概念比较独立,圈表相对比较容易,一共有 15 张表和库存直接相关,包括自营库存表 (这里有分表,实际是 12 张)、商家虚拟库存表、活动库存表和库存共享表,这些库存表之间是紧密相关的,它们一起决定了前台用户能看到的可用库存数量。
      这些库存相关的表都有商品 ID 字段,和商品基本信息表关联,我们知道,库存数量的计算不依赖于商品的具体信息。所以,这些库存表和其它表的关系比较弱,这样我们就可以比较清晰地实现库存表和其它表的切分,简化了库存服务的落地。
    在这里插入图片描述
      在微服务改造中,确定哪些表属于这个服务,会直接影响后续的所有改造工作,这需要有经验的业务架构师和数据架构师参与进来,通过深入地分析现有的业务场景和表的关系,才能对库表进行合理的划分。
      所以,你可以发现,对现有系统的改造,服务的边界划分主要是从圈表入手的,而不是从一个服务应该有哪些功能入手的,这一点和新服务设计是有所不同的。这有两方面原因:

    • 一方面,如果确定了服务包含哪些表,也就大致确定了服务有哪些功能,而表是现成的,它比业务功能要直观很多,所以从表入手比较高效;
    • 另一方面,如果从表入手,构造的服务和表是对应的,服务包含的是完整的表,不会产生一个表的一部分字段属于库存服务,而另一部分字段属于别的服务的情况,避免表字段的拆分带来额外的复杂性。
        值得注意的是,因为这是对现有系统的改造,为了避免一下子引入太多变化,我们先不对库存的表结构进行调整,表结构的优化可以放在服务的升级版里做,这样对业务系统的影响也最小。
    • 第二步是收集 SQL。在确定了哪些表属于库存服务后,我们会收集所有业务系统访问这些表的 SQL 语句,包括它的业务场景说明、访问频率等等。库存微服务后续就针对这些 SQL进行封装,提供相应的接口给业务系统使用。

      这里,服务开发团队负责提供 SQL 收集的 Excel 模板,各业务系统开发团队负责收集具体的 SQL。

    • 第三步是拆分 SQL。对于收集过来的 SQL 语句,有些 SQL 不仅仅访问圈定的这几张库存表,还会和产品库中的其他表进行关联。

      比如说,商品详情页需要展示商品详情,它会发起 SQL 查询商品基本信息表和库存表,一次性获取商品的基本信息和库存数量。针对这种情况,我们就需要把查询语句拆分为两条SQL,先查询商品表获取商品基本信息,再查询库存表获取库存数量。
      对于这样的 SQL 语句,我们就要求各个业务团队先进行拆分,保证最后提供给服务开发团队的 SQL,只包含访问库存的相关表。通过 SQL 拆分,我们切断了库存表和其他表的直接联系,等后面微服务落地后,业务系统就可以通过接入微服务,完成现有 SQL 的替换。
      SQL 拆分,会涉及一定的业务系统改造,这部分工作主要由各个研发团队负责,一般情况下,性能可能会受些影响,但问题不是很大。

    实施阶段

      完成了圈表、SQL 收集和拆分以后,接下来,我们就进入了服务实际落地的阶段。

    • 第四步是构建库存微服务。这里面包括了接口设计、代码开发、功能测试等步骤,服务开发团队会对业务方提供的 SQL 进行梳理,然后对接口做一定的通用化设计,避免为每个 SQL定制一个单独的接口,以此保证服务的复用能力。

      这部分工作由微服务开发团队负责,第一版的服务主要是做好接口设计,聚焦业务功能,以保证服务能够落地,业务系统能够顺利对接为目标。将来,服务可以持续迭代,内部做各种技术性优化,只要服务的接口保持不变,就不会影响业务系统。

    • 第五步是接入库存微服务。库存服务经过功能和性能验证以后,会由各个业务开发团队逐步接入,替换原来的 SQL语句。这部分工作主要由业务研发团队负责,难度不大,但需要耗费比较多的时间。
    • 最后一步是数据库独立。当服务接入完成,所有的 SQL语句都被替换后,业务系统已经不会直接访问这些库存的表。这时,我们就可以把库存相关的表,从原来的产品库中迁移出来,部署成为一个物理上独立的数据库。业务系统是通过服务来访问数据库的,因此,这个数据迁移对于业务系统来说是透明的,业务团队甚至都不用关心这些表的新位置。

      通过库存表独立成库,我们可以从物理层面,切断业务团队对这些表的依赖,同时,也可以大幅度降低产品库的压力,特别是大促的时候,库存读写压力是非常大的,数据库独立也为库存服务后续的技术优化打下了基础。
      这部分工作主要由微服务开发团队和 DBA 一起配合完成,主要是要避免业务系统还有遗漏的 SQL 语句,避免它们还在直接访问库存的表。我们可以在迁库前,通过代码扫描做好相应的检查工作。
      改造完成后的库存微服务架构如下图所示,库存微服务一共包含了 15 张表,对外有 30 多个接口,几十个业务系统接入库存服务。平时,库存服务会部署 50 个实例,大促时会部署更多,我们很容易通过加机器的方式,实现库存服务的水平扩展。
    在这里插入图片描述

    微服务改造小结

      到这里,我们的库存微服务就改造完成了,整个改造大概持续了 3 个月,主要是对接的工作比较耗时。
      从前面的步骤中,你可以看到,除了做好库存服务本身的设计开发工作,相关团队之间的配合也是非常重要的。
      在整个改造过程中,有很多团队之间沟通和确认的环节。比如说,服务开发团队圈定表以后,需要和业务开发团队一起确认,保证圈表的合理性;在业务团队拆分 SQL 的过程中,服务开发团队需要介入进去,帮助解决拆分时带来的性能和一致性问题;在服务接口设计和接入过程中,服务的接口可能需要重新调整,也可能有新的 SQL 进来,双方需要及时沟通,相互配合。
      这些都是纯技术层面的问题,值得一提的是,系统改造不会产生直接的业务价值,对于业务开发团队来说,他们往往还需要承担大量新需求的开发工作。所以,从项目推进的角度来看,这种核心服务的改造,很多时候都是技术一把手工程。在库存微服务改造过程中,我们也是老板高度重视,大家事先定好时间计划,每周 Review 进度,协调各个团队工作的优先级,确保改造的顺利落地。
      以上就是库存微服务改造的例子。1 号店的系统从 08 年就开始建设了,由于历史原因,形成了几个典型的大库,比如产品库、用户库等等,我们通过类似的微服务改造,逐步把这些大库拆分开,构建了一系列的基础服务,如订单服务、用户服务、产品服务、库存服务、价格服务等等。而且通过这些微服务化改造,我们同时提升了业务的复用性和系统的稳定性。
      最后,我在这里放了一张 1 号店的总体系统架构图,你可以深入看下,一个历史包袱很重的系统,它是如何经过服务化改造,最终变成一个能够高度复用和扩展的平台的。
    在这里插入图片描述

    总结

      基于现有系统进行改造和全新的服务设计是有所不同的,我们不能追求理想化和一步到位,而是要考虑到系统的平滑过渡,先实现微服务的顺利落地,后续再考虑各种优化
      今天,通过库存微服务改造的例子,提供了一种可行的微服务落地套路,可以顺利地完成老系统的架构升级。
      通过今天的分享,你对现有系统如何进行微服务化改造有了更深入的理解,希望你在实践中也能灵活运用。

    展开全文
  • 基于微服务架构重构企业OA系统的设计与实现.docx基于微服务架构重构企业OA系统的设计与实现.docx基于微服务架构重构企业OA系统的设计与实现.docx基于微服务架构重构企业OA系统的设计与实现.docx基于微服务架构重构...
  • 一种电力调度自动化系统微服务改造技术.pdf
  • 本文来自于csdn,本章介绍了通过使用微服务架构,在不影响现有业务运转的情况下,团队有效的将遗留的单块架构系统逐渐分解成不同功能的微服务应用。随着公司国际化战略的推行以及本土业务的高速发展、《网络借贷信息...
  • 后端业务系统微服务改造.docx
  • 针对当前电网信息通信运维系统存在硬件平台超期服役,信息处理任务无法快速完成等问题,本文提出一种基于Spring Could框架的微服务应用系统迁移上云改造模型,将电网信息通信运维系统迁移至云平台,模型针对集中式...
  • 一种电力调度自动化系统微服务改造技术.rar
  • 对于这样的应用系统和数据库,我们往往需要对它们进行拆分,通过微服务改造,保证系统能够不断地扩展和复用。 相比从头开始落地服务,对现有系统微服务改造,这会面临更多的挑战。 首先,应用和数据表紧密耦合...

    最新互联网大厂面试真题、Java程序员面试策略(面试前的准备、面试中的技巧)请移步GitHub


    很多早期的互联网公司都有巨大的单体应用,底层的数据表集中放在一个数据库里,这些表加起来可能有几百张。对于这样的应用系统和数据库,我们往往需要对它们进行拆分,通过微服务化改造,保证系统能够不断地扩展和复用。

    相比从头开始落地服务,对现有系统做微服务化改造,这会面临更多的挑战。

    首先,应用和数据表紧密耦合在一起,代码模块和表是多对多的依赖关系。一个模块会访问多张表,多个模块也会对同一张表进行访问,而且由于表都在一个数据库里,开发人员往往

    会随意对表做关联,有时候甚至 Join 5~6 张表以上。这样,代码模块和表之间的关系是剪不断,理还乱,我们很难清晰地划分代码和数据表的边界,也就很难把它们封装成独立的微服务。

    还有,系统现在已经在运行了,我们的改造不能影响业务的稳定性。那微服务落地后,现有的系统要怎么对接微服务,数据要怎么迁移,才能保证系统的平滑过渡呢?

    所以,要想应对这些挑战,一方面,我们要保证比较合理的服务设计,才能达到优化系统架构的目的;另一方面,我们要做到整个过程对现有系统的影响比较小,才能达到系统改造顺利落地的目的。

    接下来,我就以 1 号店库存服务化改造为例,让你深入理解,我们是如何把库存相关的功能和数据表,从现有系统里剥离出来,最终构建独立的库存服务,并实现和业务系统平滑对接的。

    改造背景和目标

    我们先来看下这次架构改造的背景和目标。

    1 号店作为一个网上超市,售卖的商品种类有数十万个,包括 1 号店自营和第三方商家的商品。由于历史原因,所有商品相关的表都存在产品库里面,这里面有产品的表(产品、分类、品牌、组合关系、属性等)、商品 SKU 的表、商家和供应商的表、库存和价格的表等等,这些表加起来,数量超过了上百张。

    我们知道,商品是电商业务的核心,几乎所有的前后台系统都需要访问这个产品库,而这些系统的开发人员,早期的时候,只关心如何实现业务功能,对这些表的访问是怎么方便怎么来,有些 SQL 语句会对大量的表做 Join 关联。所以说,虽然系统是类似分布式的,但数据库是集中式的,如下图所示:

    这样的方式,就给系统的维护带来了一系列的问题。

    • 应用方面来说,各个系统功能重复建设,比如很多系统都会直接访问库存相关的表,类似的库存逻辑散布在很多地方;另外,如果修改了库存表的某个字段,这些系统同时会受影响,正所谓牵一发而动全身。
    • 数据库方面来说,数据库的可用性是比较差的,如果某个系统有慢查询,它就很可能拖垮整个产品数据库,导致它不可用;还有,这么多系统同时访问产品库,数据库的连接数也经常不够用。

    所以,我们这次架构改造的目标,首先是对这个大数据库按照业务维度进行垂直拆分,比如分成产品数据库、库存数据库、价格数据库等等;然后基于这些拆分后的库,构建微服务,以接口的方式来支持数据库表的访问;最后将各个业务系统统一接入微服务,最终完成整个商品体系的微服务化改造。

    微服务改造过程

    你可以看到,这里涉及了多个微服务,如果同时进行服务化改造的话,牵扯太大,很难落地。于是,我们选择从库存微服务开始。一方面,库存的业务很重要,库存的规则也比较复杂,如果我们能够对库存逻辑进行优化,这会带来明显的业务价值;另一方面,电商的库存概念相对独立,涉及的表也比较少,我们可以相对容易地把它从现有体系中剥离出来。

    整个改造过程,从确定库存相关的表开始,到最后把库存表从产品库迁移出来,落到单独的库存数据库为止,一共分为两个阶段,每个阶段包含了 3 个步骤,具体如下图所示:

    • 准备阶段:这个阶段为微服务改造做好前期的准备工作,具体步骤包括了圈表、收集SQL 和 SQL 拆分。
    • 实施阶段:这个阶段实际落地微服务,具体步骤包括微服务开发、服务接入和数据库独立。

    通过这些良好定义的步骤,我们就很好地保证了整个库存微服务改造的有序和可控。接下来,我就具体说明下改造的各个步骤,包括哪些人负责哪些事情、具体的挑战在什么地方,这样,你可以深入地理解整个改造过程。

    准备阶段

    准备阶段的第一步,就是圈表。产品数据库有 100 多张表,圈表就是用来确定库存微服务具体包含哪些表,也就是确定服务的数据模型。在确定了表以后,库存微服务就负责这些表的访问,当然,库存微服务也不会访问其它的表,而业务系统后续将通过库存微服务的接口,实现对这些表的访问。

    圈表是微服务改造中比较有挑战性的地方,它实际上对应了服务的边界划分。只是针对老系统做服务化改造的时候,我们更多的是从数据库表的角度来考虑划分,这样更好落地。

    针对库存微服务来说,我们要求圈定的表,一方面要满足所有的库存访问需求,这些表之间关系紧密,和其它的表关联不大;另一方面,这些表的数量不能太多,一般不超过十几张。这样,我们既容易拆分数据库,又能控制服务的粒度,保证功能聚焦。

    在这个例子中,由于库存的概念比较独立,圈表相对比较容易,一共有 15 张表和库存直接相关,包括自营库存表 (这里有分表,实际是 12 张)、商家虚拟库存表、活动库存表和库存共享表,这些库存表之间是紧密相关的,它们一起决定了前台用户能看到的可用库存数量。

    这些库存相关的表都有商品 ID 字段,和商品基本信息表关联,我们知道,库存数量的计算不依赖于商品的具体信息。所以,这些库存表和其它表的关系比较弱,这样我们就可以比较清晰地实现库存表和其它表的切分,简化了库存服务的落地。

    在微服务改造中,确定哪些表属于这个服务,会直接影响后续的所有改造工作,这需要有经验的业务架构师和数据架构师参与进来,通过深入地分析现有的业务场景和表的关系,才能对库表进行合理的划分。

    所以,你可以发现,对现有系统的改造,服务的边界划分主要是从圈表入手的,而不是从一个服务应该有哪些功能入手的,这一点和新服务设计是有所不同的。这有两方面原因:

    • 一方面,如果确定了服务包含哪些表,也就大致确定了服务有哪些功能,而表是现成的,它比业务功能要直观很多,所以从表入手比较高效;
    • 另一方面,如果从表入手,构造的服务和表是对应的,服务包含的是完整的表,不会产生一个表的一部分字段属于库存服务,而另一部分字段属于别的服务的情况,避免表字段的拆分带来额外的复杂性。

    值得注意的是,因为这是对现有系统的改造,为了避免一下子引入太多变化,我们先不对库存的表结构进行调整,表结构的优化可以放在服务的升级版里做,这样对业务系统的影响也最小。

    第二步是收集 SQL。在确定了哪些表属于库存服务后,我们会收集所有业务系统访问这些表的 SQL 语句,包括它的业务场景说明、访问频率等等。库存微服务后续就针对这些 SQL进行封装,提供相应的接口给业务系统使用。

    这里,服务开发团队负责提供 SQL 收集的 Excel 模板,各业务系统开发团队负责收集具体的 SQL。

    第三步是拆分 SQL。对于收集过来的 SQL 语句,有些 SQL 不仅仅访问圈定的这几张库存表,还会和产品库中的其他表进行关联。

    比如说,商品详情页需要展示商品详情,它会发起 SQL 查询商品基本信息表和库存表,一次性获取商品的基本信息和库存数量。针对这种情况,我们就需要把查询语句拆分为两条SQL,先查询商品表获取商品基本信息,再查询库存表获取库存数量。

    对于这样的 SQL 语句,我们就要求各个业务团队先进行拆分,保证最后提供给服务开发团队的 SQL,只包含访问库存的相关表。通过 SQL 拆分,我们切断了库存表和其他表的直接联系,等后面微服务落地后,业务系统就可以通过接入微服务,完成现有 SQL 的替换。

    SQL 拆分,会涉及一定的业务系统改造,这部分工作主要由各个研发团队负责,一般情况下,性能可能会受些影响,但问题不是很大。

    实施阶段

    完成了圈表、SQL 收集和拆分以后,接下来,我们就进入了服务实际落地的阶段。

    第四步是构建库存微服务。这里面包括了接口设计、代码开发、功能测试等步骤,服务开发团队会对业务方提供的 SQL 进行梳理,然后对接口做一定的通用化设计,避免为每个 SQL定制一个单独的接口,以此保证服务的复用能力。

    这部分工作由微服务开发团队负责,第一版的服务主要是做好接口设计,聚焦业务功能,以保证服务能够落地,业务系统能够顺利对接为目标。将来,服务可以持续迭代,内部做各种技术性优化,只要服务的接口保持不变,就不会影响业务系统。

    第五步是接入库存微服务。库存服务经过功能和性能验证以后,会由各个业务开发团队逐步接入,替换原来的 SQL 语句。这部分工作主要由业务研发团队负责,难度不大,但需要耗费比较多的时间。

    最后一步是数据库独立。当服务接入完成,所有的 SQL 语句都被替换后,业务系统已经不会直接访问这些库存的表。这时,我们就可以把库存相关的表,从原来的产品库中迁移出来,部署成为一个物理上独立的数据库。业务系统是通过服务来访问数据库的,因此,这个数据迁移对于业务系统来说是透明的,业务团队甚至都不用关心这些表的新位置。

    通过库存表独立成库,我们可以从物理层面,切断业务团队对这些表的依赖,同时,也可以大幅度降低产品库的压力,特别是大促的时候,库存读写压力是非常大的,数据库独立也为库存服务后续的技术优化打下了基础。

    这部分工作主要由微服务开发团队和 DBA 一起配合完成,主要是要避免业务系统还有遗漏的 SQL 语句,避免它们还在直接访问库存的表。我们可以在迁库前,通过代码扫描做好相应的检查工作。

    改造完成后的库存微服务架构如下图所示,库存微服务一共包含了 15 张表,对外有 30 多个接口,几十个业务系统接入库存服务。平时,库存服务会部署 50 个实例,大促时会部署更多,我们很容易通过加机器的方式,实现库存服务的水平扩展。

    微服务改造小结

    到这里,我们的库存微服务就改造完成了,整个改造大概持续了 3 个月,主要是对接的工作比较耗时。

    从前面的步骤中,你可以看到,除了做好库存服务本身的设计开发工作,相关团队之间的配合也是非常重要的。

    在整个改造过程中,有很多团队之间沟通和确认的环节。比如说,服务开发团队圈定表以后,需要和业务开发团队一起确认,保证圈表的合理性;在业务团队拆分 SQL 的过程中,服务开发团队需要介入进去,帮助解决拆分时带来的性能和一致性问题;在服务接口设计和

    接入过程中,服务的接口可能需要重新调整,也可能有新的 SQL 进来,双方需要及时沟通,相互配合。

    这些都是纯技术层面的问题,值得一提的是,系统改造不会产生直接的业务价值,对于业务开发团队来说,他们往往还需要承担大量新需求的开发工作。所以,从项目推进的角度来看,这种核心服务的改造,很多时候都是技术一把手工程。在库存微服务改造过程中,我们也是老板高度重视,大家事先定好时间计划,每周 Review 进度,协调各个团队工作的优先级,确保改造的顺利落地。

    以上就是库存微服务改造的例子。1 号店的系统从 08 年就开始建设了,由于历史原因,形成了几个典型的大库,比如产品库、用户库等等,我们通过类似的微服务改造,逐步把这些大库拆分开,构建了一系列的基础服务,如订单服务、用户服务、产品服务、库存服务、价格服务等等。而且通过这些微服务化改造,我们同时提升了业务的复用性和系统的稳定性。

    最后,我在这里放了一张 1 号店的总体系统架构图,你可以深入看下,一个历史包袱很重的系统,它是如何经过服务化改造,最终变成一个能够高度复用和扩展的平台的

    总结

    好了,下面我总结一下今天所讲的内容。

    基于现有系统进行改造和全新的服务设计是有所不同的,我们不能追求理想化和一步到位,而是要考虑到系统的平滑过渡,先实现微服务的顺利落地,后续再考虑各种优化。

    今天,我通过 1 号店库存微服务改造的例子,给你提供了一种可行的微服务落地套路,让你可以顺利地完成老系统的架构升级。

    展开全文
  • 遗留系统改造微服务

    2020-02-21 19:51:06
    随着企业规模的扩大以及...这就造成遗留系统改造微服务比新系统直接使用微服务方式开发更复杂,在这个复杂的过程,寻求业务与技术上的平衡。 系统改造原由 1、新开发人员维护系统存在大量知识盲区,一些业务规则...

           随着企业规模的扩大以及微服务技术的逐渐成熟,更多企业开始尝试使用微服务的方式进行系统开发。但是技术的转型并不能一蹴而就,因为一般技术部门要保持需求的开发进度,所以研发并不能停下需求研发,而单单做技术的转型。这就造成遗留系统改造微服务比新系统直接使用微服务方式开发更复杂,在这个复杂的过程,要寻求业务与技术上的平衡。

    系统改造原由

    1、新开发人员维护系统存在大量知识盲区,一些业务规则只有特定人员才知道,缺少文档记录,系统随着开发人员变动而越发不可控

    2、在现有系统上实现新功能或修改现有功能非常困难,最后演变成不敢修改而不得以不断打补丁支撑,测试回归成本过高

    3、不利于维护,沟通,协作,某个服务部署或者宕机,会影响整个业务链

    4、随着规模扩大,海量用户以及高并发,不能快速水平与垂直扩展

    遗留系统改造微服务——关注要点

    1、目的性 所有改造的过程基本上都是为了系统的高性能,高可用,可扩展,可伸缩,支撑未来业务的飞速发展。

    2、在遗留系统中优先寻找核心,关键功能,发挥改造的最大价值。

    3、注重业务模块拆分和重建,粒度上保证功能的独立性和完整性,减少链路调用,并且拆分服务能为其他模块复用,实现1+1>2的效果

    4、改造过程要分清两个基本概念,重构≠重写,虽然重写好处诸多,但是现有系统生产环境稳定运行,贸然重写会引发很多问题,而没有明显收益

    面向服务设计

    1、通用功能下沉,成为独立子模块

            用户系统,权限系统,文件存储,即时通信,消息推送,支付系统,短信平台,社交服务,上述列举都是较为通用的功能,根据遗留系统的复杂度以及具体业务拆分,一个原则保证功能独立性以及完整性,减少链路调用

    2、最大限度的复用,分布式中间件对服务的整合

            服务网关(用户鉴权,路由,灰度发布)

           分布式调度系统,分布式缓存机制,分布式消息中间件,搜索引擎,日志系统,分布式发号器等

    循序渐进的改造过程

           1、代码重构,减少冗余代码,提高可读性

           2、使用适配器模式(在不同子系统适配,确保应用不受外部子系统的影响),门面模式(拦截路由)实现新旧平滑迁移

           3、共享数据库,新服务复用旧服务的数据库,减低使用风险,提高改造速度(减少新旧系统开发成本)

    测试驱动开发

          重构过程难免无意中影响现有逻辑行为,导致系统引入缺陷。

          1、在重构前测试用例和之前逻辑一样,单元测试要尽可能覆盖核心逻辑,不盲目追求覆盖率,追寻二八原则,以提高项目后期的单元测试的收益率

           2、自动化测试等手段减少回归测试成本

    面向失败设计

           在微服务设计中,存在各种风险造成程序异常。在改造初期就要考虑服务降级,流量控制,接口熔断,分布式事务等方式去拥抱失败

    灰度发布

            为了减少改造对线上的影响,引入灰度发布机制,可以保证系统稳定,控制影响范围,及早发现并解决问题

    日志聚合和全链路监控

            服务的拆分,日志被每个模块独立拆分,为了减少后期解决问题的耗时以及复杂性,规范的日志体系,便于后续的日志聚合检索

            全链路追踪监控,在微服务中加上"服务名称"便于定位异常发生具体模块,根据全句的TraceID,串联整个调用链,以便详细分析。

    几句心里话

           自从入职公司一直希望做全新的系统,希望使用新的技术,面对以前的老系统想用现在的技术重构。但是做了新的系统,慢慢的新系统自己都不乐意维护了,新系统也做成老系统的模样。一心倡导把现在有系统改造成微服务的方式,却忽略与微服务配套的相关内容。自身的技术不硬,做什么最后都做成了那般模样。当我开始认真考虑系统改造的时候,第一个问题如何粒度上保证功能的独立性和完整性,减少链路调用,就把自己困住了怎样都没有更好的方案。然后跳出自己的困境,整体思考公司的架构,确实存在系统过于庞大的问题,但是其他已经做了拆分,只不过是相比其他服务目前正在做的服务,过于庞大了,其原因也是在后续的开发过程服务的独立性没有把握好。我在反思与其将现有服务拆分,不如想想怎么做好服务的支撑工作,当我们有成套的解决方案,遗留系统改造,一切问题都会迎刃而解。

            希望类似处境朋友们,结合上边的方法认真思考是,是意愿问题,还是确实刚需。无论哪种原因,都好好考虑除了业务模块还有因为服务引发的系列问题,虽然一开始可能没办法做不了大而全,但是也不能忽略。

     

    展开全文
  • - 干货分享 -任何人类的设计都会腐化,很遗憾软件尤其会...其实,对于单体系统,也可以按照上下文拆分领域。如果这样做了,再把代码级的领域拆分为部署视角的微服务,也不是那...
  • 微服务改造 对单体架构现状的不满和难以控制是推动微服务改造的重要因素,企业在向微服务架构转型的过程中面临诸多挑战,需要采用相应的策略模式进行微服务改造。 技术债务 单体架构下技术债务的产生原因...
  • 业务系统微服务改造方案.docx
  • 1.优先剥离较独的边界服务(如短信服务、地理位置服务),从核的服务出发,减少拆分对现有 2.当两个服务存在依赖关系时,优先拆分被依赖的服务 1.服务接的调,不再
  • 随着公司国际化战略的推行以及本土业务的高速发展,后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同,从销售团队准备材料、与客户签单、递交给合同...
  • 下面的黄色部分代表passport和支付系统,这个是在做得到之前就存在的系统,因为公司早期有微信里的电商业务。后来发现有一些业务逻辑并不需要从得到走,还有一些数据格式转换的工作也不需要跟业务完全耦合,所以加了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 24,571
精华内容 9,828
热门标签
关键字:

哪些系统要微服务改造