分布式架构、微服务架构介绍
JeeSite Cloud 具备 JeeSite 4.x、 (opens new window)的所有功能，是在 JeeSite 4.x、5.x 基础之上，完成的 Spring Clou分布式系统套件的整合。它利用 JeeSite 4.x、5.x 的开发便利性巧妙地简化了分布式系统开发。
JeeSite Cloud 并没有重复制造轮子，它只是将目前比较成熟的、经得起实际考验的服务框架组合起来，通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理，重新了设计架构和新增了很多实用的工具，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发平台。
集成阿里优秀组件 Nacos 服务治理与配置中心、集成 Sentinel 流量卫兵；集成 Zipkin 链路追踪；集成 Seata 分布式事务等，详见技术选型章节。
主要特点：用经典开发模式，开发分布式微服务应用，上手简单，开发快
什么场景下，需要用 JeeSite Cloud 微服务：
-
微服务化的核心就是将传统的系统，根据业务进行拆分一个个的小服务，一个服务出现问题不会有影响其他服务的运行
-
某一个服务并发要求比较高时，可单独增加该服务节点（如果传统应用，需要整体增加会浪费资源）提高服务可用性
-
可直观的看到服务的运行状态，可统一配置各个微服务的配置参数，统一的基础数据管理（人员组织基础架构）
我们的优势
-
在 JeeSite 单应用基础之上，完成的 Cloud 功能，使用经典开发模式，就像开发单应用一样开发分布式应用
-
它提供了微服务模块的代码生成工具，快速生成开发微服务功能，包含微服务的发布和调用接口
-
我们将 api 和 client 合体为一个工程，自动适应自己调用自己 client 的影响，简化工程数量
-
解决 Feign 接口不能多重继承问题，如一些通用操作（增删改查）微服务接口基类实现，这些都不用自己写了
-
统一的授权认证、基础数据微服务，都已经提供查询 client 接口，其他微服务应用模块中可直接获取用户、组织、权限、字典等基础数据。微服务之间调用中，出现的会话及缓存的一致性统一得到解决。
-
如 UserUtils、EmpUtils、EmpUserService、OfficeService 等等众多的基础服务工具类，都可以直接从基础数据的微服务中获取数据，你不必考虑跨 web 服务的数据交互，我们已经帮你做了。
-
微服务组件 Nacos、Sentinel、Zipkin 源码方式启动部署，方便开发调试，无需单独在 IDE 外运行。
-
支持 Gateway 网关动态路由，用户可在不重启服务的情况，随时调整路由规则，高度灵活性管理。
-
使用 Seata AT 事务管理，入侵性小，跨 web 服务的情况、支持单个微服务独立数据库。
-
集成工作流，提供BPM引擎独立的服务，客户端只需调用API，无需加载复杂流程引擎。
-
支持两套前端技术选型实现，全栈版(Bootstrap+Beetl)、分离版（TS+Vue3+Antdv)。
-
其它优势（按 Ctrl + Shift 点击链接）：http://jeesite.com/docs/feature/
软件即服务（SaaS）架构、多租户架构
SaaS 是 Software-as-a-Service（软件即服务）的简称，从技术角度上可称之为 “多租户技术或称多重租赁技术”。它与 “按需软件、应用服务提供商、托管软件” 所具有相似的含义。它是一种通过互联网提供软件的模式，厂商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得厂商提供的服务。用户不再需要购买软件，而改用向提供商租用基于Web的软件，来管理企业经营活动，且无需对软件进行维护，服务提供商会全权管理和维护软件，软件厂商在向客户提供互联网应用的同时，也提供软件的离线操作和本地数据存储，让用户随时随地都可以使用其定购的软件和服务。对于许多小型企业来说，SaaS是采用先进技术的最好途径，它消除了企业购买、构建和维护基础设施和应用程序的需要。
“多租户技术或称多重租赁技术” 是一种软件架构技术，是实现如何在多组织环境下共用相同的系统或程序组件，并且可确保各租户间数据的隔离性。在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴。
特点：
-
在 JeeSite 中维护了一套多租户框架，能够实现开发过程无知感的多租户实现方式。
-
开发人员不需要考虑多租户的太多细节，根据配置规则，有多租户框架完成数据隔离。
-
支持多租户规则配置（java包、java类、分库模式、分库独立），方便进行配置：
-
哪些功能数据，需要进行租户数据隔离（如：业务数据）；
-
哪些功能数据，需要租户之间共享（如：基础配置数据）。
-
支持特权数据管理，租户切换，方便管理和查询多租户下的数据
-
支持给租户管理员分配不同的角色权限，不同的租户功能不同
实现方案及原理
多租户的数据隔离方案，不外乎以下三种方案（来自网络转载）分别是：
1）独立数据库
这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。
优点： 为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
缺点： 增多了数据库的安装数量，随之带来维护成本和购置成本的增加。这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。
2）共享数据库，隔离数据架构
这是第二种方案，即多个或所有租户共享 DataBase，但是每个租户一个 Schema（也可叫做一个user）。
优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；
缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；如果需要跨租户统计数据，存在一定困难。
3）共享数据库，共享数据架构
这是第三种方案，即租户共享同一个 DataBase、同一个 Schema，但在表中增加 corp_code 多租户的数据字段。这是共享程度最高、隔离级别最低、维护成本和购置最低的模式。
优点： 三种方案比较，第三种方案的维护和购置成本最低，跨租户统计方便，允许每个数据库支持的租户数量多。
缺点： 隔离级别最低，需要在设计开发时加大对安全的开发量；对单个租户的数据备份和恢复困难。
如果希望以最少的服务器为最多的租户提供服务，并且租户接受牺牲隔离级别换取降低成本，这种方案最适合。