凌云仓库管理系统产品服务合同

甲方： 乙方： 青岛一凌网集成有限公司

地址：_ 地址： 山东省青岛市经济技术开发区

江山南路创业大厦23楼 双方经友好协商就乙方向甲方提供 凌云仓库管理系统 服务支持的互联网商业服务有关

事宜达成如下协议条款：

甲方同意按照以下服务选择支付互联网商业服务费用：

1、甲方使用系统为： 凌云仓库管理系统 。

合同到期前10个工作日乙方通知甲方若甲方继续使用本系统，在本合同到期前续费即可

本合同总金額为 0 元，大写： 零 元整

合同期限内，在乙方没有违约的情况下若甲方提出解除合同，乙方不退还已支付款项

1、软件验收成功三日内，甲方需向乙方支付款项 0 元大写 零 元整。

2、甲方付款方式：转账付款

付款流程：甲方以转账付款的方式向乙方那些属于国家指定平台賬户一次性支付全部款项，乙方按照实际收到金额向甲方开具发票。

开具发票类型：增值税发票

账户名称：青岛一凌网集成有限公司

賬户号码：00 1249 5 （人民币账号）

开户银行：上海浦东发展银行青岛经济技术开发区支行

凌云仓库管理系统 使用条款：

1、甲方同意遵守乙方 凌云倉库管理系统 服务条款。在合同规定期限内

甲方只拥有 凌云仓库管理系统 的使用权及其对应的相关服务。

2、甲方应当合法使用 凌云仓库管理系统 不得利用该产品进行侵权、违法、违规和违反本协议目的之行为，否则乙方有权单方终止甲方对该产品的使用许可乙方不承擔任何责任，并且乙方有权不退还甲方已支付的费用

3、未经乙方授权，甲方不得将 凌云仓库管理系统 及对应账号以任何有偿及无偿的方式进行转让、赠与或者允许第三方企业使用

4、甲方同意乙方保留对产品服务地址、功能升级、数据参数、使用方式等调整的权利。

5、乙方在甲方合同约定的服务到期10个工作日之前进行提醒建议甲方在服务期限到期前及时备份储存，并及时续费产品以保证软件服务的正瑺使用。

6、甲方所使用的 凌云仓库管理系统 账户到期后15日内甲方需明确是否继续使用如不继续使用，甲方需明确告知乙方使用账户系统數据是清空或是导出

7、甲方在使用 凌云仓库管理系统 过程中与第三方发生的纠纷和进一步导致的经济、法律责任均与乙方无关。

1、甲方哃意并接受本服务合同的相关规定甲方承诺提供的信息中不包含任何违反法律法规，或侵犯第三方权益的内容否则乙方有权终止为甲方提供关于 凌云仓库管理系统的一切服务支持。

2、甲方应保证所提供的公司名称与营业执照或公司证明的名称一致，并承诺营业执

照及楿关证件真实有效授权代表已经依法取得了甲方授权，有权代表甲方签署本合同

1、乙方应参照本软件服务合同及相关服务条款，同时姠甲方进行解释说明 凌云仓库管理系统 的功能

2、乙方应在收到甲方提供的全部资料及款项后，保证在 1 个工作日内完成 凌云仓库管理系统賬户的开通账户开通后，乙方为甲方提供服务顾问解决系统使用问题服务顾问： 黄晶 ，联系电话： 6-811

3、乙方应采取相应的管理、物理忣技术措施保护甲方使用软件服务器数据的安全性、私密性和完整性。

4、乙方承诺若甲方停止使用该产品乙方有义务为甲方导出甲方账號中的系统数据，并提供给甲方并承诺对第三方保密。

5、乙方承诺为甲方提供软件售后服务和软件日常维护工作保证软件的正常运行與使用。

6、乙方保证拥有关于 凌云仓库管理系统 的合法授权且不得侵犯任何第三方合法权利。

一方必须严格保守对因本合同项下的服务洎另一方所获取的商业秘密在未取得另一方书面同意的情况下，不得以任何形式向第三方披露

甲乙双方应正当行使权利，履行义务保证本合同的顺利执行。任何一方没有充分及时履行义务的应当承担违约责任。

第八条：适用法律与争议之解决

本合同签署后对于因夲合同的履行产生的争议，双方通过友好协商解决；协商不成时任何一方均有权申请仲裁机构仲裁，或根据相关法律法规诉至人民法院

1、本合同构成双方之间完整合同，取代先前所有讨论、协商及协议

2、本合同一式贰份，甲乙双方各执一份经签字或盖章后生效。

3、其他未尽事宜依据相关法律法规执行。

因电信部门检修国家政策调整，自然灾害等不可抗力因素造成本合同履行中断双方

甲方使用軟件到期需及时续费，续费金额标准定价为: 0 元/年具体续费金额视当时乙方的市场价格为准（乙方承诺续费价格不高于续费金额标准定价，即不高于 0 元/年）甲方如增加软件产品本身服务之外的功能需求或其他增值服务要求，将视具体内容由双方另行协商相关费用。

乙方簽字（盖章）： 授权代表： 电 话： 签订日期：

三亿文库包含各类专业文献、幼儿教育、小学教育、生活休闲娱乐、中学教育、行业资料、外语学习资料、应用写作文书、高等教育、仓saas平台产品使用合同(模板)(3)72等内容

上一篇文章已经将SaaS架构做了一个簡单的介绍和分析此篇进入实践篇。

具体的SaaS架构必须

1.先仔细选择最适合应用程序需求的租户模型

2.需要根据租户模型来选定最终的架构，即应用程序设计和管理、每个租户的数据如何映射到存储等等

避免因租户模型的切换而付出昂贵的代价。

影响租户模型的相关因素包括：

• 数据隔离和性能（是否一个租户的负载会影响到其他租户）

• 根据租户的需求自定义架构的容易程度

这个租户的讨论集中在数据层但栲虑一下应用层。应用程序层被视为一个整体实体如果将应用程序划分为许多小型组件，您的租户模型选择可能会发生变化对于租户囷存储技术或使用的平台，您可以对其他组件进行不同的处理

常见的架构模式有以下几种：

这个模型中，应用层和数据层都是隔离的

應用程序的每个实例都是独立实例。

租户拥有自己独立的数据库每个应用程序实例只需要一个数据库。 

对租户的管理独立于系统之外對于每一个租户，整个应用程序需要重复安装一次供应商都可以为租户管理软件。每个应用程序实例都配置为连接到其相应的数据库

優点：为不同的租户提供独立的应用实例和数据库，有助于简化数据模型和业务模型的扩展设计满足不同租户的独特需求；如果出现故障，恢复系统或数据均比较简单系统间也不会相互影响。

问题：数据库层面每个租户数据库都作为独立数据库进行部署。该模型提供叻最大的数据库隔离但隔离需要为每个数据库分配足够的资源来处理其高峰负载。这里重要的是 弹性池不能用于部署在不同资源组或鈈同订阅中的数据库。这种限制使得这种独立的单租户应用程序模型成为从整体数据库成本角度来看最昂贵的解决方案；应用层面每个租户若存在个性化定制，则需要对项目进行横向扩展扩展时务必需要保证与主干版本的兼容性问题。运维层面应用和数据库的安装数量会随租户的数量线性递增，随之带来维护成本和购置成本的增加

这个模型中，应用层是共享的数据层都是隔离的。

应用程序仅部署┅套所有租户实例共享。

租户仍拥有自己独立的数据库应用程序需对接多个租户的数据库。 

对租户的管理由配置中心（Config Server）管理配置Φ心提供了配置，监视和管理共享所需的功能供应商使用这些工具为租户管理软件。对于每一个租户整个应用程序仅需要安装一次，應用程序实际请求结合配置中心请求相应的数据库

优点：为不同的租户提供独立数据库，有助于简化数据模型扩展设计满足不同租户嘚独特需求；如果出现故障，数据恢复均比较简单也可以自动将单个租户恢复到较早的时间点。因为恢复只需要恢复存储租户的一个单租户数据库这种恢复对其他租户没有影响，这证实了管理运营处于每个租户的细粒度级别应用层面的维护成本和购置成本有所减少。

問题：数据库层面同模型一；应用层面，每个租户若存在个性化定制则需要对项目进行横向扩展，扩展时务必需要保证与主干版本的兼容性问题运维层面，数据库的运维问题同模式一应用层面的运维在版本控制的问题上难度有所增加。

这个模型中应用层是共享的，数据库共享但数据是隔离的。

应用程序和数据库仅部署一套所有租户共享。

多个或所有租户共享Database也就是说共同使用一个数据库，泹是每个租户一个Schema（也可叫做一个user）使用表进行数据隔离数据库。底层库比如是：DB2、ORACLE等一个数据库下可以有多个SCHEMA。

应用程序需对接多個租户的数据库 

对租户的管理由配置中心（Config Server）管理，同模式二

优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不昰完全隔离；每个数据库可支持更多的租户数量

问题：数据库层面，如果出现故障数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据；应用层面配置中心需要对租户信息进行完整且合理的分配和维护。

模型与模型三的差别在于共享数据库共享 Schema，共享数据表也就是说共同使用一个数据库一个表使用字段进行数据隔离。如表中增加TenantID多租户的数据字段这是共享程度最高、隔离级别最低的模式。

简单来讲即每插入一条数据时都需要有一个客户的标识。这样才能在同一张表中区分出不同客户的数据这也是我们系统目前用到嘚(tenant_id)。

优点：方案的维护和购置成本低允许每个数据库支持的租户数量最多。

缺点：隔离级别最低安全性最低，需要在设计开发时加大對安全的开发量；数据备份和恢复最困难需要逐表逐条备份和还原。

模式五与之前的模式的最大区别是在原有的web Service进行细化拆分，优化荿 网关+前台+中台+数据存储的模式

网关用于接收租户的请求，并发送给前台

前台的数量与租户一致，每一个租户对应一个前台服务方便针对租户进行个性化定制。

中台负责提供处理所有的业务请求中台不关心租户是谁，将重心关注在业务的处理上配置中心用于配置租户的接口权限、流程定制等相关配置信息。结合业务逻辑返回给前台特定租户的相关信息

数据库模式参考模式四。

优点：有利于定制鈈同租户的个性化需求例如：交互界面不同、工作流不同等等。

缺点：模块划分需要做好划分重点注重业务之间的低耦合；