微服务架构是当前主流的企业应用架构。经过几年的实践，它的优点和缺点也广为人知了。
微服务的优点
- 业务相对独立：有自己的缓存、消息队列、数据库、应用程序。也就是说在业务上就对数据、程序进行解耦。
- 对性能的扩展相当于容易：某个模块的服务处理能力不足的时候，我们只需要增加这个模块的资源或者是优化它的程序即可。
- 发布简单：单体架构中，所有代码都在一共应用中，所有每次发版都是整个应用一起发。而微服务架构中，只要保证接口不变，模块是可以单独发布的。
- 技术异构：对于不同的模块，只需要保证接口不变就可以了，而内部使用说明语言架构都可以。
微服务的坑
- 业务拆分：在实际的业务中，很难对一些特定的职责进行情绪的划分。而不同的划分又会带来系统难度的提升。
- 微服务粒度拆分：业务是不停的改变的，当拆分粒度过粗，随着业务的发展，又会形成新的单体。当拆分粒度过细，微服务之间的依赖、联调、测试、部署就会变的非常复杂。
- 系统整体整体架构不清楚：随着业务的发展版本的迭代，微服务也越来越多，当达到几百个微服务的时候，基本上就没有人知道整个系统的全貌了，如果出了问题，是很难定位是哪个模块出来什么问题的。
- 消耗更多硬件资源：单体架构是，只需要服务器，数据库，缓存。拆分微服务后，每个服务都有自己的服务器、数据库、缓存，服务和服务之间往往还需要消息队列来完成。为了保险起见，每个服务至少需要部署在 2 个节点以上，再加上网关层需要 2 台以上服务器。整个硬件投入翻了几倍。
- 分布式事务：对于单体应用来说事务可以直接提交给数据库来执行即可。微服务就麻烦的多了，例如：某个流程出错是否需要将数据全部回滚？如果需要的话，那么我们需要在每个流程中写上回滚代码。那万一回滚失败了呢？我们是不是还需要写回滚的回滚代码等等。
- 服务之间的依赖：随着业务的发展，微服务越来越多，服务于服务直接的依赖也越来越多，这种地狱式的依赖，无论是排错、新版本开发、还是运维都非常麻烦。
- 联调：在微服务中，一个模块需要调用多个其它服务。而在软件开发中，最影响项目排期的往往不是技术、人力的问题而是第三方依赖的问题，一旦涉及沟通、协调等问题就会特别耗时间！直接的结果就是导致整个软件开发的周期变长！
- 部署：因为微服务系统往往会调用几十个甚至上百个微服务，所以不可能在本地本地部署完后再联调，必须搭建一个套联调的环境。并且这个环境还要保证数据的完整性和稳定性。
函数式架构的思想
背景：在企业应用中，对已有系统，开发需求，是否越开发越难，随着时间的推移，人员的流动，系统越来越无法维护，新的需求 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只需要一个数据集群即可。所需要的硬件不到微服务的三分之一。