架构本质和微服务,你了解吗?

开发 架构
服务是动词,对业务流程进行封装和抽象。封装针对业务深度,如下单服务封装下单一系列处理过程。抽象针对业务广度,支持类似的业务流程,如普通商品/虚拟商品/团购商品下单。

图片图片

好的架构就像优美的散文,行散神不散。

什么是服务

业务封装

服务是动词,对业务流程进行封装和抽象。封装针对业务深度,如下单服务封装下单一系列处理过程。抽象针对业务广度,支持类似的业务流程,如普通商品/虚拟商品/团购商品下单。

组件复用

进程外调用,接口无状态;

职责聚焦,边界明确;

独立开发,独立部署。

图片图片

Case分析Case分析

下单服务

粗粒度 SOA

提供端到端的功能,对应用友好

服务内部实现复杂,访问一系列库表,对象之间有大量计算,耦合紧密

如果需求有变化,整个大服务跟修改和重新部署。

下单逻辑聚合

微服务

  • 每个子服务高度聚焦,边界清晰,独立数据模型
  • 需要上层应用做服务聚合,一般简单组装即可
  • 需求有变化,修改对应子服务。因子服务提供功能完备,一般应用方调整聚合逻辑即可(比如虚拟商品下单,可以跳过发票/发货环节)。

图片图片

图片图片

图片图片

图片图片

图片图片


落地建议

粗粒度SOA

  • 系统业务之间比较独立,耦合度不高,面向具体业务需求,提供流程端到端处理,如OTA业务。
  • 业务流程比较固定,直接封装,如银行转账。

微服务

  • 业务流程环节多,易变,为每个处理节点构造微服务,允许调整,如电商下单。
  • 业务广度和深度都非常复杂,互相关联,通过主数据服务打造微内核,简化依赖并允许上层自由组合,如B2C电商业务。

微服务改造步骤:

图片图片

1. 圈定访问表

步骤:

  • 确定哪些表是某个服务所专用的,并且不允许其他服务访问这些表。例如,订单服务可能会访问订单主表和订单明细表,但不允许其他服务访问这些表,订单服务也不会访问其他服务的表。

目的:

  • 通过明确表的访问边界,减少服务之间的耦合,确保数据访问的安全性和一致性。

2. 收集SQL

步骤:

  • 收集各个应用对指定表的所有SQL访问需求。
  • 如果某些SQL涉及到关联其它表,则需要先将这些SQL进行拆分,确保每个SQL只涉及到单个服务的表。

目的:

  • 了解所有的SQL访问需求,为后续的优化和设计提供依据。

3. 提炼SQL整体设计

步骤:

  • 对收集到的SQL访问需求进行分类和提炼。
  • 进行总体设计,如统一缓存、优化查询等,以提升系统性能。

目的:

  • 通过提炼和优化,减少重复的SQL访问,提升数据库访问的效率。

4. 开发接口

步骤:

  • 根据提炼后的SQL需求,开发相应的服务接口。
  • 确保这些接口能够满足各个应用的SQL访问需求。

目的:

  • 提供统一的服务接口,简化应用的开发和维护。

5. 应用接入

步骤:

  • 各个应用逐步接入新的服务接口。
  • 可以边开发边上线和接入,确保平稳过渡。

目的:

  • 通过逐步接入,减少对现有系统的冲击,确保平稳过渡到新的微服务架构。

6. 独立迁库

步骤:

  • 在条件允许的情况下,可以考虑将表的schema进行修改,并将数据迁移到独立的数据库。
  • 彻底与现有的库表分开,确保新的微服务架构的独立性。

目的:

  • 通过独立迁库,进一步减少服务之间的耦合,提高系统的可维护性和扩展性。

B2C电商系统架构:


图片图片


业务应⽤层

  • 包括不同业务线的应用,如自营、商城、无线、商家、供应商和第三方。这些业务应用通过业务接口调用底层的组件和服务,实现具体的业务功能。
  • 具体的业务模块如Mobile(移动端)、CMS(内容管理系统)、分类、详情页、广告、搜索、购物车、结算、订单管理、物料信息、账户管理、CRM(客户关系管理)等。

组件化/服务层

  • 这一层主要负责具体的业务逻辑和功能实现,通过组件和服务提供给上层业务应用调用。
  • 主要包含应用服务和基础服务:

应用服务

  • 下单(OMS、Shopping):负责处理订单管理和购物相关的业务逻辑。
  • 促销、个人中心、精准化、评论、PMS(商品管理系统):处理促销活动、用户个人中心、精准营销、用户评论和商品管理相关的业务。
  • 客⼾服务(Invoice、GRS(退货管理系统)):处理客户服务和发票、退货相关的业务。
  • YCM(优惠券管理)、PIS(库存管理系统)、团购、Coupon(优惠券):处理优惠券、库存管理、团购和其他促销活动。
  • Search、AD(广告)、Store、特卖、Finance(财务)、Payment(支付)、更多服务:处理搜索、广告、商店、特卖、财务、支付等其他服务。

基础服务

  • 产品服务:处理产品信息的管理。
  • 库存服务:管理库存相关的数据和操作。
  • 价格服务:管理商品价格和定价策略。
  • 用户服务:管理用户信息和用户操作。
  • 订单服务:管理订单相关的数据和操作。
  • 支付服务:处理支付相关的操作和数据。

数据层

  • 这一层负责数据的存储和管理,包含了不同类型的数据仓库:

Product:产品数据。

User:用户数据。

Stock:库存数据。

Order:订单数据。

Wireless:无线相关数据。

SBY:可能是某个特定业务线的数据(需要具体上下文来确认)。

BI:商业智能相关的数据。

大数据:大数据平台,用于存储和分析大量业务数据。

缓存平台

  • 提供了系统的缓存功能,以提升数据访问的速度和系统的响应时间。

这个架构展示了一个分层清晰、职责明确的电商平台架构,通过不同层次的分工和协作,实现了复杂业务需求的处理。每一层都有特定的职责,从数据存储、基础服务,到业务逻辑和具体应用,实现了高效的业务处理和良好的扩展性。

关键点:

  • 分层设计:每一层都有明确的职责,确保了系统的模块化和可维护性。
  • 组件化服务:通过组件化和服务化的设计,提高了系统的灵活性和可扩展性。
  • 数据管理:数据层管理着不同类型的业务数据,通过统一的数据平台支持上层业务应用。
  • 缓存机制:通过缓存平台提升了系统的性能和响应速度。
责任编辑:武晓燕 来源: 二进制跳动
相关推荐

2016-09-26 14:45:46

微服务

2024-05-10 08:46:13

微服务架构技术

2021-10-18 08:52:42

技术

2022-04-28 08:12:29

函数调用进程切换代码

2018-10-19 10:49:53

云原生架构无服务器

2018-07-30 08:23:30

微服务架构设计

2020-01-09 15:30:32

微服务架构互联网

2014-02-10 10:13:43

2020-02-08 16:46:29

微服务架构复杂

2023-07-10 09:27:36

分层架构服务架构

2023-01-07 10:17:06

微服务架构模式

2023-08-28 16:12:36

架构微服务数字化

2022-03-14 07:53:27

ELTETL大数据

2022-11-09 16:23:17

Python微服务架构

2023-07-28 09:23:24

微服务架构

2018-10-28 18:09:22

微服务Microservic架构

2024-05-17 16:18:45

微服务灰度发布金丝雀发布

2024-01-19 11:57:42

2024-09-23 17:05:44

2020-10-29 08:55:04

微服务
点赞
收藏

51CTO技术栈公众号