关于微服务:超越微服务架构

微服务架构是以后支流的企业应用架构。通过几年的实际，它的长处和毛病也广为人知了。

微服务的长处

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 业务

A 的业务给 A 提了一个需要，而这个需要，须要批改 B 能力实现，而批改的 B 还不能影响 C 的性能实现。B 版本 1 适配 A 的新需要，同时还得满足 C 的性能实现。

随着业务的倒退，行业规定，监管的变动。共享的代码适配的性能就会越来越多，越来越简单。

2、函数式企业应用架构的准则是 — 业务隔离，而不是共享

也是用下面的例子，如果 A 有新的需要须要批改 B，在函数式架构中，复制一份 B 进去，取名为 B1 间接批改外面的代码即可，不必思考是否还兼容 C 的问题。这个 B1 就是 A 独享的。随着业务的倒退，也不会呈现代码臃肿，逻辑凌乱，不可保护的状况，因为业务代码的流程十分清晰，且实现了业务的隔离，一个业务的变动，不会影响其它业务的扭转！

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

这里有人可能会有一个疑难：” 既然函数式有这么多长处，为什么当初大多数还是命令式的？”。这个就要说到编程语言的倒退了，其实最早的编程语言，就是函数式的 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只须要一个数据集群即可。所须要的硬件不到微服务的三分之一。