原创投稿
  1. 趣知天下事首页
  2. 科技
  3. 技术

业务层，到底需不需要服务化？

糖太宗 • • 技术 • 阅读 25
很多公司，都实施了微服务架构，底层抽象出很多基础数据服务。
业务层，到底需不需要服务化？
基础数据的访问服务化之后，架构如上：
（1）站点业务通过RPC接口，调用基础数据服务；
（2）基础数据服务通过DAO，从db/cache获取数据；
（3）db/cache存储数据；
 
除了基础数据的访问需要服务化，业务层是否需要服务化？如果需要，什么时机进行服务化？这是本文要讨论的两个问题。
随着时间的推移，系统架构并不会一成不变：
（1）随着业务越来越复杂，业务会不断进行垂直拆分；
画外音：以58同城为例，有招聘、房产、二手、二手车、黄页等多个业务。
（2）随着数据越来越复杂，基础数据服务也会越来越多；
画外音，例如：用户服务，订单服务，搜索服务，推荐服务等。
 
业务层，到底需不需要服务化？
于是系统架构变成了上图这个样子，业务垂直拆分，有若干个基础数据服务：
（1）垂直业务要通过多个RPC接口访问不同的基础数据服务，服务共享是服务化的特征；
（2）每个基础数据服务访问自己的数据存储，数据私有也是服务化的特征；
 
上面架构图中的依赖关系是不是看上去很别扭？
（1）基础数据服务与存储层之间连接关系很清晰；
（2）业务站点层与基础数据服务层之间的连接关系错综复杂，变成了蜘蛛网；
 
再举一个更具体的例子，58同城列表页站点如何获取底层的数据？
（1）首先调用商业基础服务，获取商业广告帖子数据，用于顶部置顶/精准的广告帖子展示；
（2）再调用搜索基础服务，获取自然搜索帖子数据，用于中间自然搜索帖子展示；
（3）再调用推荐基础服务，获取推荐帖子数据，用于底部推荐帖子展示；
（4）再调用用户基础服务，获取用户数据，用于右侧用户信息展示；
（5）…
 
如果只有一个列表页这么写还行，但如果有招聘、房产、二手、二手车、黄页等多个业务，都这么获取共性数据，而只有少部分个性数据，每次都这么一个个调用基础服务，有大量冗余、重复、每次必写的代码。
 
特别的，不同业务上游列表页都依赖于底层若干相同服务：
（1）一旦一个服务RPC接口有稍许变化，所有上游的系统都需要升级修改；
（2）子系统之间很可能出现代码拷贝；
（3）一旦拷贝代码，出现一个bug，多个子系统都需要升级修改；
 
如何让数据的获取更加高效快捷呢？
业务服务化，通用业务服务层的抽象势在必行。
 
业务层，到底需不需要服务化？
通过抽象通用业务服务层，例如58同城“通用列表服务”：
（1）业务站点层，可以通过RPC接口，像调用本地函数一样，调用通用业务服务，一次性获取所有通用数据；
（2）通用业务服务，也可以通过多次调用基础数据服务提供的RPC接口，分别获取数据，底层数据获取的复杂性，全都屏蔽在了此处；
是不是连接关系也看起来更清晰？
这样的好处是：
（1）复杂的从基础服务获取数据代码，只有在通用业务服务处写了一次，没有代码拷贝；
（2）底层基础数据服务接口发生变化，只有通用业务服务一处需要升级修改；
（3）如果有bug，不管是底层基础数据服务的bug，还是通用业务服务的bug，都只有一处需要升级修改；
（4）业务站点层获取数据更便捷，获取所有数据，只需一个RPC接口调用；
 
业务层，到底需不需要服务化？
于是，当业务越来越复杂，垂直拆分的系统越来越多，基础数据服务越来越多，底层数据获取复杂性成为通用痛点的时候，就应该抽象出通用业务服务，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。
 
最后再强调两点：
（1）是否需要抽象通用业务服务，和业务复杂性，以及业务发展阶段有关，不可一概而论；
画外音：如果没有多个业务线，大概率基础服务就够用。
（2）需要抽象什么通用业务服务，和具体业务相关；
画外音：帖子列表业务服务，帖子详情业务服务，是58同城特有的；而基础服务，例如用户，订单，支付等基础服务，基本上各个公司是类似的。
 
任何脱离业务的架构设计，都是耍流氓。
 
调研：
（1）贵司有没有基础服务？
（2）贵司有没有业务服务？

发布者：糖太宗，转载请注明出处：https://www.qztxs.com/archives/science/technology/6587

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
糖太宗糖太宗
0 0
上一篇 2022年5月14日 上午12:41
下一篇 2022年5月14日 上午12:42

相关推荐

  • WEB开发中，使用JSON-RPC好，还是RESTful API好

    简单来说：不管哪个“好”还是不“好”，RESTful API在很多实际项目中并不实用。因此真的做了项目，你可能会发现只能用HTTP+JSON来定义接口，无法严格遵守REST风格。 为什么说不实际呢？因为这个风格太理想化了，比方说： REST要求要将接口以资源的形式呈现。但实际上，很多时候都不太可能将一些业务逻辑看作资源。即使强制这么干了，也会非常非常别扭。登...

    糖太宗 糖太宗
    技术 2022年5月12日
    1600
  • 面试杀手锏：Redis源码之SDS（Redis 数据结构源码解析） 技术

    面试杀手锏：Redis源码之SDS（Redis 数据结构源码解析）

    1.前言 Hello，欢迎大家来到《 Redis 数据结构源码解析系列》，在《Redis为什么这么快？Redis底层实现原理》一文中我说过 ，Redis 速度快的一个原因就是其简单且高效的数据结构。（新手建议反复多推敲几遍） 2.SDS命令实战[初来乍到] SDS 是 Redis 中最简单的数据结构。Redis 中所有的数据结构都是以唯一的 key 字符串作...

    糖太宗 糖太宗
    2022年5月19日
    3100

  • 甲方安全建设的一些思路和思考

      0x00 前言 本文主要是介绍一下笔者对于甲方安全能力建设的一些经验，心得和零散的思考。需要特别强调的是不同企业的实际情况不尽相同，本文仅供参考，不具普遍意义。   0x01 Red Teaming 近几年随着Red Team建设的话题越来越流行，不管是甲方或者乙方都在极力的发展自己的Red Teaming能力，尤其是各个乙方都推出了...

    常山赵子龙 常山赵子龙
    技术 2022年5月28日
    2100

  • OpenVPN + Ldap + OTP

    OpenVPN 服务端的一些配置 VPN是企业内比较重要的一个资产，不能从网上乱下载，去官网看看 https://openvpn.net/，第一次不懂事，不清楚OpenVPN还有商业版，OpenVPN Access Server 和 OpenVPN Community，直接就安装了OpenVPN AS，没有网上说的那么难，还有图形化界面，登陆进行发现2个并发...

    常山赵子龙 常山赵子龙
    技术 2022年5月28日
    76000

  • 信息安全规划文档的编写 （转发）

    0-00 安全规划的目的 组织安全部门建立到运行一段的时间，工作阶段从救火到标准化的过程就需要考虑编制和实施适合自己组织的安全规划了。 编写安全规划主要为以后的工作进行合理的估计和安排，从结构上提升组织的安全水平，大概是从杂牌军到正规军的转变，也有可能现有的方法满足不了实际业务的需求，需要重新规划、设计。   0-01 安全规划应该包含的内容 安全...

    常山赵子龙 常山赵子龙
    技术 2022年6月16日
    2800

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

联系我们

400-800-8888

在线咨询： QQ交谈

邮件：admin@example.com

工作时间：周一至周五，9:30-18:30，节假日休息

关注微信