公有云上基于微服务架构SAAS产品研发实践

于济萌

作者 | 刘学斌
编辑 | 济萌

作者简介

刘学斌
用友畅捷通 架构专家

用友畅捷通信息技术股份有限公司架构专家，擅长领域驱动设计建模、微服务架构设计、应用安全开发、持续集成、DevOps、业务分析建模、开发流程设计等领域。有大型企业组织实施持续集成、应用安全开发、DevOps、架构设计实践经验。目前任职用友畅捷通云产品研发部，专职企业云产品微服务架构设计、企业应用建模（领域建模、物理建模、流程建模），坚信并实践DDD建模解决复杂业务问题之道。

序言

随着云计算技术的日益发展、开源技术与云计算融合的程度进一步加深，微服务架构得到越来越多业界的关注。这种微服务架构技术在给我们带来方便的同时，也带来了很多技术的复杂性。

如何充分利用微服务给我们带来好处，同时避免微服务带来技术的复杂性和数字的一致性的一些弊端，把这些东西降到最小化，就需要我们必须用合适的方法、手段和工具进行开发以及架构设计。

本文将分享微服务架构在SaaS下的产品研发实践及应用。

本文的九个部分：
1. 产品研发背景；
2. 问题分析；
3. 设计目标和思路；
4. 研发组织架构；
5. 研发规范；
6. 研发流程；
7. 分析设计方法；
8. 实施方案；
9. 总结。

一、产品研发背景

用友通公司过去一直面向小微企业提供软件包服务。在中国小微企业数量特别多，小微企业的特点是：企业多，但是每个企业的业务量相对比较少。因为他们没有固定的人做系统管理、维护和使用，并且整体IT水平也不高，所以这类企业非常适合用微服务。

近几年随着云技术的发展，社会上出现大量的业务创新，像电子支付、电子云仓和电子发票。这些东西都是商业基础设施，那么对小微企业来说，如何把SaaS服务和社会上的一些商业基础设施有利的集成起来，集中起来，为我所用，SaaS服务就成为了唯一的选择。

二、问题分析

我们的客户主要是面向那些小微企业、工贸公司、贸易公司和小的制造商，单个企业来说业务并不复杂；但是，做一款产品要满足这么多企业和行业的不同需求，这个问题可能会变得并不简单。

另外，云产品要保证在7×24小时内始终运行，并且在这个始终运行的产品上给它做升级和维护，这是非常高风险的事情。所以，对架构和模型来说，就提出了一个很高的要求，既：架构和模型能够根据需要来随时滴进行演进。

三、设计目标和思路

基于刚才的问题和背景，我们当时提出来几个设计目标。
第一个是产品架构支持大规模并发用户需要；
第二个是模型和架构支持持续、快速演进；
第三个是希望通过这种方式，在开发微服务的产品过程中，积累一些企业基本的基础业务能力经验，将这些经验为未来研发其他产品所共用。这样会加快新产品的创新和研发速度。

基于以上几个目标我们设计了几个思路。

第一个是作为产品来说我们非常重视设计，我们力求在架构设计保障项目中，将保持“跑得快”与“跑得远”之间的平衡。

第二个是充分使用成熟的第三方开源技术和资源，专注我们自己擅长的业务领域。

第三个是在时间和资源紧迫的情况下，我们会分离技术点，完成简单实现。

第四个是按照DDD方法对问题域进行分解，使用微服务架构业务能力。

最后，我们会做出稍微超前的模型设计，以满足未来的业务变化需要。同时，这样也可以降低将来业务变更的风险。

四、研发组织架构

现在研发跟过去不一样，由于现在设计的专业性比较强，所以我们分了很多小组。例如产品：UI/UE，前端、后端、测试、运维、业务运营。整个一套组织体系就是这样产生的。

五、研发规范

有了合适的规范工作成果便更容易被理解，也对开发有好处；所以，我们制定了大量的规范。

采用微服务架构这种模式，把以前一个单体的利用拆分成几十个或上百个微服务架构。这对DevOps也是一个挑战，所以实行自动化的微服务的DevOps也是一个挑战。

六、研发流程

研发流程共有五个步骤。

第一步是本地开发。新的开发一般是用DeveLop，然后是三个分支：develop、test和release。这样将开发、测试和发布进行空间上隔离。

第二步是开发人员从develop分支下载最新版本，并构建、发布到Nexus。构建成功之后，通过自动任务将Nexus上的snapshot包发布到“AutoTesting”环境，然后在该环境上执行自动集成测试。

第三步是自动测试成功之后，将步骤一中构建的包发布到develop环境。

第四步是在develop环境中由开发人员完成人工确认和验证。

最后，在人工确认完成之后，驱动自动任务将develop中内容merge/rebase到test分支，并完成后续test分支的构建和发布任务。

七、分析设计方法

在分析设计方法中，我们做微服务架构方法不仅仅使用一种技术方式，还会根据具体情况，采用相应的设计方法。设计方法有：概述、业务建模、系统建模、领域模型和物理模型。

第一是概述。任何一种方法都需要工具来支撑，无论做分析、设计还是需求，我们都需要有合适的工具。那么，分析和设计基本用这两种建模工具：一个是ENA，另一个是ERWin。我们采用DDD的设计方法，是微服务模式进行建构。

第二是业务建模。业务建模包括：系统建模、领域建模和物理建模。业务建模是把整个组织都作为一个研究对象。领域建模是通过事物的现象和外观来洞悉事物本质。物理建模就是落实到表。

另外，在业务建模中我们需要知道什么叫组织？对于一个小微企业，组织可能是一个公司或者我们服务的一个组织中的部门，我们把它作为一个研究对象。它是一个系统组织，组织里的角色和系统相互协作完成一些业务，输出业务价值。

业务建模之后，我们可以得到系统的外观，然后通过系统建模知道系统里面到底有哪些组件组成或者有哪些模块组成，这些模块之间是怎么进行协作的。

第三，系统外观是通过分析得到的。我们通过业务流程得到系统外观；然后，我们得到是有来源的系统需求。系统里面由什么组成？系统里面必须分离复杂性，把系统拆成一个个小块，叫模块。这些模块之间怎么相互协作，满足系统外观里面所要求的功能，这就是业务系列图。通过这种方式，对于不特别复杂的系统，就会很容易得到它的每个模块的外观。

第四，得到外观以后，我们要得到它里面的东西是什么呢？如果把人看做一个系统的话，人能跑能跳，我们得到他的领域模型有腿有脚，并且他里面有一些概念，以及概念之前的关系是什么，这也是要表达的。这是属于知识层，可以帮助我们理清思路。

最后，物理模型是面向的是物理的表，就是我们到时候进入这个东西，工具和建库脚步。直接把表建好，用转向的工具可以进入表，生成代码，成生软数据都可以。

物理建模之后，我们通过插件生成源代码。虽然我们建立了模型，但不是所有的设计都能实现代码生成。如果定义这个模型后再看代码的时候，是非常好看的，也就是说我的模型和代码一致，模型和现实就是一致的，这样理解起来也更容易。

八、实施方案

基于SaaS产品我们有一些实施方案，其中包括几项技术选择，可以帮助解决复杂性的问题。例如：租户模式、分层设计、应用架构、总体技术架构、模块技术架构和在微服务架构下，分布式环境下的一致性。

8.1.租户模式

什么叫租户模式？租户模式就是SaaS产品中的一个应用，并且很多用户都可以使用同一套应用来共享同一个计算资源和存储资源。

我们有不同的租户模式：
第一个是虚机模式，即每个租户有独立的虚机、独立的应用和独立的DB；
第二个是租户独立DB模式，即虚机和应用是共享的，但是不同的租户使用独立的DB。
第三个是租户共享DB模式，即虚机、应用和DB都是共享的。但是，DB共享不代表数据共享，数据可能还独立的；就是说DB是一个，表也是一个，只是所有租户共用一个表。

对于这三种模式来说，如果资源共享，资源利用率就会变得很高。举个例子：就虚机模式来说，虚机是独立的，即每个租户使用一个虚机；那么就会产生一些租户忙或一些租户闲，我们就可以将租户闲的资源分配给租户忙的使用。相比来说，DB和虚机都是共享模式，那么它的资源利用率比较高；而且抵抗波动的能力也比较强。

对于企业用户量不大，转化率不高，最好采用第三种模式就是虚机、应用、DB都是共享的模式。第一种模式一般是适用于大型企业，因为他们需要独立的虚机来开发一些定制化的产品。

8.2.分层设计

PC推动了分层的方式，它分离复杂性，这通常是分离的关注点。我们把整个应用分为四层，第一个是前端；然后是后端；其中，后端业务层面又分成了两层，上面是应用服务层，下面的是支持子域层也叫能力层。

首先，说说能力层和应用层之间的区别是什么？能力层是提供业务能力，那么什么叫能力？例如，每个人都有自己的学习和表达能力，这些都叫能力；而，一个人的工作经验就是他曾经做过什么，这也叫能力，所以将这些能力称之为能力层。什么事应用层？简单来说，解决具体问题的层叫应用层。

在后端里，我们需要把应用层和能力层这两个分开。底下的是通用、核心和支持，就是支持业务的某一方面。在具体实践过程中，还有一些常用的和通用的，也就是大家都使用的一些业务服务放在这个层面上，像计量单位、授权和产品元数据等。例如作为我们的产品来说，计价也是一个很复杂的服务，包括促销也是一个非常复杂的服务；还有核心领域层，核心领域层是面向核心业务的，像我们通常意识到企业的一些部门采购等。

8.3.应用架构

上图想大家揭示了在模块里面的几种架构模式，也是DDD里面通常采用的方式。

8.4.总体技术架构

通过上图所示，大家可以进一步了解领域层是怎样设计的，以便将来更好地设计、规划和建设业务架构。

8.5.模块技术架构

建模是提高应用质量最核心的东西，代表了真正的业务核心竞争力，而不是采用具体什么技术。

8.6.一致性方案

对于微服务来说，它存在一个弊端就是一致性的问题。这是非常复杂的问题，而且无论你怎么做，无论采用什么方案只是避免不一致的发生，但是不可能回避掉不一致性；也就是说只能减少不一致事件发生概率，不能真正回避不一致事件的发生。

在这里，强一致性（TCC）是我们自己采用的方案，而弱一致也是采用消息的方式。对于TCC方案来说，它的特点是：要求数据状态强一致，操作原子性并实时返回结果。

我们采用的最终一致性方案是TCC+MQ事物方案。这种方案的好处是：在分支是系统情况下，它的业务和性能肯定是比子系统还要快速的降低，所以我们必须把一些业务进行分析，知道那些业务可以通过消息进一步异步化，从而增加客户相应速度，进而增强体验。

九、总结

通过讲解，对上述的内容作出如下的总结：

1. 相对传统软件包产品，云产品升级是一个高风险的活动，设计灵活领域架构是云产品的灵活应对业务变化的基础；
2. 与业务专家合作，按照领域驱动设计方式对总体架构进行拆分 ，DDD中Bounded Context对标微服务模块；
3. 微服务依赖复杂性是个坑，按照DDD方式对微服务切分为三层，上层只能依 赖同层和下层，有效控制了微服务依赖的复杂性；
4. 领域模型是表达业务功能（表象）背后的业务本质的模型，领域模型属于知识级模型，具有更高的稳定性，在云产品开发中，领域模型质量直接关系到产品的质量；
5. 微服务给发布和运营带来了复杂性，自动化的 DevOps能力是实施微服务必 要条件 ；
6. 建立云产品研发体系，构建公司基础业务服务能力，包括核心业务服务能力、支持业务服务能力和通用业务服务能力，大力缩短后期产品研发创新周；
7. 专注自身的核心竞争力，充分使用业界成熟的技术和服务。