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

读服务+写服务分离架构，我坚决反对！

糖太宗 • • 技术 • 阅读 23

系统分层架构有一个迭代和演进的过程，早期，系统二层架构如下：

读服务+写服务分离架构，我坚决反对！
（1）上游是业务应用；
（2）下游是数据库；
 
随着架构的演进，可能要抽取出微服务，系统三层架构如下：
读服务+写服务分离架构，我坚决反对！
（1）上游仍是业务应用；
（2）中间是微服务层，提供RPC接口；
（3）下游是数据库；
 
大家都知道，数据库可以读写分离，为了职责更清新，架构设计上，服务能否读写分离呢？
读服务+写服务分离架构，我坚决反对！
如上图，服务化读写分离之后：
（1）业务方通过RPC分别调用读服务和写服务；
（2）服务层分为读服务与写服务；
（3）底层是高可用的数据库集群；
 
读服务+写服务分离架构，我坚决反对！
当然，也有可能读服务与写服务读写的是不同的数据库，如上图：
（1）写服务访问写库；
（2）读服务访问读库；
写库与读库是一个主从同步的集群。
 
那么，问题来了：
（1）你遇到过这种读服务+写服务分离的架构设计么？
（2）这种架构设计好还是不好，为什么？
 
楼主支持这种读写服务分离的架构设计么？
先说结论，我旗帜鲜明的反对服务区分读写分离。
 
为什么反对呢？
大大小小的理由，有这么五点。
 
第一点：对于调用方而言，调用同一个基础服务，要访问其RPC接口，究竟调用读服务，还是写服务，容易困惑。
 
第二点：对于同一个基础服务，服务数量翻倍了，运维更加复杂。
画外音：总的来说，上面两点还可以忍。
 
第三点：一般来说，服务拆分，是按照“子业务”维度进行拆分，而不是按照“读写”维度进行拆分，这是模块化设计的基本准则。
画外音：这一点，是原则性问题。

 

第四点：完全打破了“服务化数据库私有”的微服务初衷。
画外音：数据访问，应该收口。
 
两个服务因为同一份数据库资源访问而耦合在一起，当数据库资源发生变化的时候（例如：ip变化，域名变化，表结构变化，水平切分变化等），有两个依赖点需要修改。

 

读服务+写服务分离架构，我坚决反对！
而好的设计，有变化产生时，只有一个需要修改（低耦合，高内聚）。
第五点：没法很好的添加缓存。
画外音：这一点很致命。
大部分互联网业务是读多写少的业务，数据库读取最容易成为瓶颈，常见提升读性能的方式是，增加缓存。
读服务+写服务分离架构，我坚决反对！
如上图，读服务的下游增加一个缓存，当有读请求访问时：
（1）先访问缓存，如果命中，直接返回；
（2）如果缓存不命中，访问数据库，然后将数据放入缓存中，以便下一次能够命中；
 
额，然后，这个架构中，这个方案是不可行的。因为，写服务修改数据库时，缓存中的数据没有办法得到淘汰！！！
 
OK，有朋友说，写数据库之前，可以由写服务来淘汰缓存：
读服务+写服务分离架构，我坚决反对！
即，读服务与写服务都可以操作缓存。额，这个设计，又违背了“服务化缓存私有”的微服务初衷，两个服务因为同一份缓存资源访问而耦合在一起，当缓存资源发生变化的时候，有两个依赖点需要修改。
画外音：缓存访问，应该收口。
 
况且，如果真的两个服务访问相同的数据库和缓存，为什么不合成一个服务呢？
读服务+写服务分离架构，我坚决反对！
硬要拆成两个服务，不是自己玩自己么？
 
OK，有另外的朋友说，可以由写服务发消息来淘汰缓存：
读服务+写服务分离架构，我坚决反对！
如上图：
（1）缓存私有，只有读服务操纵缓存；
（2）数据库发生写请求时，写服务给MQ发消息，由读服务来淘汰缓存；
 
这种设计：
（1）读服务来淘汰缓存，本质是一个写请求，不是很奇怪么？
（2）引入了一个MQ组件，引入更大的一致性风险；
（3）读服务和写服务如果是一个进程，岂不是更好么，干嘛硬要跨进程通信呢？
 
所以，还是一个服务更好：
读服务+写服务分离架构，我坚决反对！
（1）调用方不蒙圈，不纠结；
（2）好维护；
（3）数据库，缓存私有，无耦合；
 
总的来说，个人的意见是：
互联网微服务架构，建议按照“子业务”进行微服务拆分，而不应该按照“读写”来进行微服务拆分，避免过度设计。
 
以上仅为个人架构经验，希望逻辑是清晰的，供大伙参考，欢迎共同探讨。
调研：
你遇到过读写服务分离的架构设计么？
 
小手一抖，好文转走读服务+写服务分离架构，我坚决反对！

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

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
糖太宗糖太宗
0 0
上一篇 2022年5月12日 下午11:52
下一篇 2022年5月13日 下午8:12

相关推荐

  • ubuntu搭建xunfeng资产扫描系统

    0x00 前言 巡风是一款适用于企业内网的漏洞快速应急、巡航扫描系统，通过搜索功能可清晰的了解内部网络资产分布情况，并且可指定漏洞插件对搜索结果进行快速漏洞检测并输出结果报表。 网络资产识别引擎会通过用户配置的IP范围定期自动的进行端口探测（支持调用MASSCAN），并进行指纹识别，识别内容包括：服务类型、组件容器、脚本语言、CMS。 漏洞检测引擎会根据用户...

    常山赵子龙 常山赵子龙
    技术 2022年5月27日
    1200
  • 为什么微服务并不是越早越好？ 技术

    为什么微服务并不是越早越好？

    微服务架构，是分层架构演进过程中很重要的一环，那微服务是不是越早越好呢？今天和大家一起聊聊这一个问题。 什么时候进行DAO层的分层抽象？ 最开始，分层架构长什么样? 一个业务系统最初的分层架构如上： （1）web-server层从db层获取数据并进行加工处理； （2）db层存储数据；   此时，web-server层如何获取底层的数据呢？ web-serve...

    糖太宗 糖太宗
    2022年5月14日
    2900

  • frida hook 简单使用

    拿到一份APP渗透测试报告，里面有一个运行日志残留（中危），该日志中保留大量运行日志，其中包含了一些敏感信息，攻击者可以根据该日志获取应用运行的信息，为进一步攻击做准备 我对APP客户端测试比较初级，残留日志我一般会使用adb logcat打印一下或者在程序目录下翻一翻。并没有发现日志中存在敏感信息，问了下测试的工程师，是通过源代码分析找到相关日志类，hoo...

    常山赵子龙 常山赵子龙
    技术 2022年6月13日
    3100
  • 互联网分层架构，为啥要前后端分离？ 技术

    互联网分层架构，为啥要前后端分离？

    有水友在评论中留言问我： 沈老师，我在一家创业公司，大概有20人左右的研发团队。   团队正在推进前后端分离，我觉得架构变得复杂了，项目研发周期变长了，但组长说，互联网公司都在搞前后端分离，所以我们也要搞。   我还是不理解，为什么要进行前后端分离呀？ 今天，简单说说，互联网分层架构里的前后端分离。 画外音：“别人在搞xxoo技术”一定不能成为，一家公司推动...

    糖太宗 糖太宗
    2022年5月14日
    2700
  • 凭啥修改代码的是我？原来这就是耦合！ 技术

    凭啥修改代码的是我？原来这就是耦合！

    你有没有遇到过这样的场景？ （1）硬件升级，要换一台高配机器； （2）网络重新规划，若干服务器要调整机架； （3）服务器当机，要重新部署恢复服务； …   更具体的，如上图：数据库换了一个ip，此时往往连接此数据库的上游需要修改配置重启，如果数据库有很多上游调用方，改配置重启的调用方会很多，每次换ip的成本往往很高，成为大家共性的痛点。   由A的调整（数据...

    糖太宗 糖太宗
    2022年5月12日
    2900

发表回复

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

联系我们

400-800-8888

在线咨询： QQ交谈

邮件：admin@example.com

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

关注微信