超越微服务架构

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: DawnSql完美超越微服务

DawnSql完美超越微服务

微服务架构是当前主流的企业应用架构。经过几年的实践,它的优点和缺点也广为人知了。

微服务的优点

  1. 业务相对独立:有自己的缓存、消息队列、数据库、应用程序。也就是说在业务上就对数据、程序进行解耦。
  2. 对性能的扩展相当于容易:某个模块的服务处理能力不足的时候,我们只需要增加这个模块的资源或者是优化它的程序即可。
  3. 发布简单:单体架构中,所有代码都在一共应用中,所有每次发版都是整个应用一起发。而微服务架构中,只要保证接口不变,模块是可以单独发布的。
  4. 技术异构:对于不同的模块,只需要保证接口不变就可以了,而内部使用说明语言架构都可以。

微服务的坑

  1. 业务拆分:在实际的业务中,很难对一些特定的职责进行情绪的划分。而不同的划分又会带来系统难度的提升。
  2. 微服务粒度拆分:业务是不停的改变的,当拆分粒度过粗,随着业务的发展,又会形成新的单体。当拆分粒度过细,微服务之间的依赖、联调、测试、部署就会变的非常复杂。
  3. 系统整体整体架构不清楚:随着业务的发展版本的迭代,微服务也越来越多,当达到几百个微服务的时候,基本上就没有人知道整个系统的全貌了,如果出了问题,是很难定位是哪个模块出来什么问题的。
  4. 消耗更多硬件资源:单体架构是,只需要服务器,数据库,缓存。拆分微服务后,每个服务都有自己的服务器、数据库、缓存,服务和服务之间往往还需要消息队列来完成。为了保险起见,每个服务至少需要部署在 2 个节点以上,再加上网关层需要 2 台以上服务器。整个硬件投入翻了几倍。
  5. 分布式事务:对于单体应用来说事务可以直接提交给数据库来执行即可。微服务就麻烦的多了,例如:某个流程出错是否需要将数据全部回滚?如果需要的话,那么我们需要在每个流程中写上回滚代码。那万一回滚失败了呢?我们是不是还需要写回滚的回滚代码等等。
  6. 服务之间的依赖:随着业务的发展,微服务越来越多,服务于服务直接的依赖也越来越多,这种地狱式的依赖,无论是排错、新版本开发、还是运维都非常麻烦。
  7. 联调:在微服务中,一个模块需要调用多个其它服务。而在软件开发中,最影响项目排期的往往不是技术、人力的问题而是第三方依赖的问题,一旦涉及沟通、协调等问题就会特别耗时间!直接的结果就是导致整个软件开发的周期变长!
  8. 部署:因为微服务系统往往会调用几十个甚至上百个微服务,所以不可能在本地本地部署完后再联调,必须搭建一个套联调的环境。并且这个环境还要保证数据的完整性和稳定性。

函数式架构的思想

背景:在企业应用中,对已有系统,开发需求,是否越开发越难,随着时间的推移,人员的流动,系统越来越无法维护,新的需求 bug 越来越多?系统的代码,逐步成为了一堆 "屎山"。每次做新的需求前需要仔仔细细的对 "屎山"进行考古,即使这样也不能完全保证,新的需求上去会不会影响现有的功能或者性能。

上面问题的本质,就是系统的 "可变性" 造成的!

1、现在通常的企业应用架构

现有的软件架构中,架构师们往往强调,业务共享,例如:有三个业务 A, B, C 其中 A 和 C 共享 B。本来岁月静好,没有想到 A 的业务给 A 提了一个需求,而这个需求,需要修改 B 才能完成,而修改的 B 还不能影响 C 的功能实现。因此就必须写一个新的 B 来适配 A 的新需求,同时还得满足 C 的功能实现。当业务的规模发展太快或者行业规则变化太快时就会有很多这样的需求,而业务早就不是 A B C ... N 了。这样的话,当年的小甜甜就变成了牛夫人,大家发现随着业务的发展,开发人员正常的替换,共享的业务代码会越来越臃肿,越来越不可维护, 逻辑也越来越混乱。直到最后彻底无法满足业务的需求。

例如:
一个开始,A C 共享 B 业务

4_1.jpg

A 的业务给 A 提了一个需求,而这个需求,需要修改 B 才能完成,而修改的 B 还不能影响 C 的功能实现。B版本1 适配 A 的新需求,同时还得满足 C 的功能实现。

4_2.jpg

随着业务的发展,行业规则,监管的变化。共享的代码适配的功能就会越来越多,越来越复杂。

2、函数式企业应用架构的原则是 -- 业务隔离,而不是共享

也是用上面的例子,如果 A 有新的需求需要修改 B ,在函数式架构中,复制一份 B 出来,取名为 B1 直接修改里面的代码即可,不用考虑是否还兼容 C 的问题。这个 B1 就是 A 独享的。随着业务的发展,也不会出现代码臃肿,逻辑混乱,不可维护的情况,因为业务代码的流程非常清晰,且实现了业务的隔离,一个业务的变化,不会影响其它业务的改变!

4_3.jpg

函数式架构的思想来至与函数式编程。强调业务的不可变性!事实上,函数式的思想是最符合人类的思维的。

这里有人可能会有一个疑问:"既然函数式有这么多优点,为什么现在大多数还是命令式的?"。这个就要说到编程语言的发展了,其实最早的编程语言,就是函数式的 lisp 语言。因为函数式语言的不可变性,惰性求值的特点,使得中间的计算过程产生的值无法共享给其它程序。在当时计算机硬件落后的情况下,这种特点就不如,命令式高效了。例如:命令式语言 C/C++/JAVA 等,在运算过程中对变量进行赋值,而其他的线程也可以访问和修改这个变量,使得这个变量被其它线性所共享。也就是说只需要计算一次,其它的都共享这个结果。这显然比函数式要高效。但是随着计算机硬件的发展多核多线程,成为主流,命令式语言的共享,带来了严重安全和性能问题,因为线程等待会严重的影响性能,而函数式都是不可变的,所以在多核多线程下,它会拥有更好的性能和开发效率。

3、函数式应用架构的难点

3.1、根据业务对数据权限控制。让其业务在数据层面隔离。

3.2、对相应的业务的代码和相关联的代码,进行复制的能力

DawnSql对函数式架构的支持

1、在 DDL 中增加 schema 的支持。

schema 相当于数据表的集合。当新建用户组的是,需要给它指定一个 schema。默认它可以读写同一个schema 中的所有表,当然也可以给它添加权限视图,让它的读写权限受到限制。如果一个用户组要读写其它 schema 中的表,就一定要设置权限视图!
具体使用:创建和删除 schema
根据业务新建 schema,在新建的 schema 中添加相应的表,具体的例子在 测试数据下载地址

2、添加用户组

用户组是 DawnSql 创建的一个新概念,在DawnSql 所有的用户程序,必须属于一个用户组。
1、 用户组默认只能访问,自己所在用户组的表、no sql 和方法。
2、 可以通过权限视图给用户组赋予,访问表的权限,可以通过内置函数 add_scenes_to 来给其它用户组赋予,访问方法的权限。

-- 例如:创建一个用户组
-- 名称为 wudafu_group
-- user_token: wudafu_token
-- all,表示这用户组内的 schema 拥有 DDL 和 DML 的执行权限。也可以是 DDL 或者 DML
-- wudafu 表示已经存在的 schema
add_user_group('wudafu_group', 'wudafu_token', 'all', 'wudafu');

3、为用户组添加权限

可以通过 my_view 方法给用户组添加读写表的权限,也可以通过 rm_view 方法删除用户组的表权限。
具体用法:为用户组删除访问数据集和表的权限。(需要 root 权限)

schema、用户组、用户权限,这三个功能就可以将整个系统,按照逻辑来拆分成不同的用户组,并对不同的用户组设置权限。当业务自己会 sql 或者是会使用 excel,只需要读取功能,或者是部分写功能的时候,可以为业务设置一个用户组,这样业务可以通过 DBeaverWeb 来操作数据库!这样的好处是对于这种需求,就不需要做系统了。既提升了业务的满意度也降低了企业的运营成本!

4、执行分布式事务

DawnSql本身就支持分布式事务,且效率很高。(分布式事务二阶段提交)
具体用法:事务

5、DawnSql 程序的部署

DawnSql 脚本写好后,同过测试用例,就可以直接提交到 DawnSql 的数据库中了,这里 DawnSql 脚本既是程序也是数据。测试的 DawnSql 集群可以通过 JDBC 将 DawnSql 脚本直接部署到生产环境中。测试集群建议和生产集群配置一致!

6、DawnSql开发的建议

DawnSql 脚本通过测试,发往生产后。当新的需求来的时候,我们建议新建 DawnSql 脚本,如果新建的脚本可以,直接复制上一个版本的脚本来修改,只是脚本的名称不一样,这样旧的脚本,照样可以在其它方法中正常使用。开发人员只需要专注新的需求即可。

DawnSql与微服务架构的成本比较

开发成本

微服务需要一支全部成员为专家级的团队,且开发同样的需求,因为拆分成不同的微服务、带来了用性、数据完整性、事务性、状态等问题,需要开发人员额外处理,并且对业务有入侵性。同时因为服务之间的依赖、联调、部署、运维的人力成本非常高。
DawnSql支持业务和数据的隔离性,支持分布式事务,支持 NoSql 等,让开发者只需要用DawnSql 语言描述业务即可。

硬件成本

微服务的每个服务均需要独立的数据库、缓存、服务器、消息队列。此外还需要网关平台、注册平台、配置平台、消息平台、链路平台、日志平台、均需要单独的机器。还有主备的切换,微服务对硬件的成本要求很高。
DawnSql只需要一个数据集群即可。所需要的硬件不到微服务的三分之一。

相关文章
|
18天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
17天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
21天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
79 6
|
21天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
32 1
|
17天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
37 1
服务架构的演进:从单体到微服务的探索之旅
|
15天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
38 8
|
16天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5
|
19天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
44 7
|
17天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5
|
17天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####