业务视角下的微服务架构设计实例

资讯频道 → 行业应用

4顶
1踩

2017-06-05 16:58 by 副主编 jihong10102006 评论(0) 有23903人浏览

微服务

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

引用

作者：林帆，ThoughtWorks咨询师
责编：魏伟，欢迎云计算、大数据领域技术投稿、约稿、给文章纠错，请发送邮件至weiwei@csdn.net
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅《程序员》

导读：本文以某汽车产品代理商的线上销售和售后平台为例，介绍它在微服务转型过程中遇到的种种情况，希望能以此作为前车之鉴，让后来者避开不必要的趟坑。

前言

近年来，服务化和微服务的架构随着线上业务对响应变化和发布频率要求的不断提高已经变得日益常见。像DevOps和Docker等理念和技术的成熟也在为这一趋势推波助澜。许多企业对微服务思考的关注点也从最初的“该不该用”、“该如何用”逐渐转向“如何评价服务拆分的好坏”、“服务拆分后的数据如何治理”这样更加具体而实际的方面。纵观社区里与微服务有关的话题，既有一些适合大众阅读的概念入门科普文章，也有一些像“架构去中心化”、“消息异步解耦”、“最终一致性补偿”这类专业性的技术讨论，但却很少看到能够比较深入的介绍微服务实施经验，说清楚“什么地方会有什么坑”这类问题的实践性内容。

若将微服务的方方面面铺开，将是一个非常庞大而复杂的知识体系。万事开头难，如何迈出服务划分的第一步是对于那些从未采用过微服务的项目首先要面对的问题。虽然服务的划分本来是一件十分凭借架构师个人经验和对业务理解的主观工作，但其中仍然有些规律可循。根据服务的类型特点，可以有以下几种常见的方式：

根据业务进行建模，依据业务领域的边界划分，这也是当下微服务社区十分推崇的领域驱动设计（Domain Driven Design，简称DDD）方法
根据资源使用类型划分，这种方式主要使用在对硬件资源需求很高、或对特定硬件类型/区域地址等存在依赖的大型服务系统，例如系统的某些功能非常消耗CPU、或是某些功能必须在有加密狗设备的机器上运行。此时可以依据系统各部分对不同资源的需要作为边界进行最安全的划分，以最大化运行效率
根据数据边界划分，直接从数据表结构或数据源着手，依据数据归属关系界定服务。这种划分方法简单粗暴且能避免数据耦合，但容易导致潜在隐患，甚至可以被认为是一种反模式。仅仅对于强数据驱动的系统，如某些报表系统和多数据源ETL系统等适用，在实际案例中很少见

从现实上来说，我们平时遇到的绝大部分系统都是需要为特定终端用户群体服务的。因此，采用基于业务领域的建模的方法通常都会是个不错的选择，它也是目前在划分服务问题中的最主流的方法。不过即使有了理论指导的支撑，服务划分里的利弊权衡并不是非黑即白的事情，依然存在不少模棱两可之处，只有在犯下一些错误后才能摸索出适合自己系统的方法。本文将会聚焦在这些点。

没有什么能比一个具体而贴近真实的案例更具有代表性了。因此，我们将剖析一个传统行业企业的线上业务：某汽车产品代理商的线上销售和售后平台，介绍它在微服务转型过程中遇到的种种情况，希望能以此作为前车之鉴，让后来者避开不必要的趟坑。这个案例中讲述的场景原型并非完全来自同一个项目，而是从我们过去一年中所经历的多个项目的实际场景抽取出来的，去除了其中的敏感信息，并添加了基于真实情况的适当演绎，使之更加完整。简单介绍一下案例的背景：这是一家颇具规模的汽车代理商企业，承接多个国际一线品牌汽车的销售和周边资源整合的业务，具有庞大的实体店网点。其线上的IT业务系统已经存在了十余年，提供的功能从最初的进销存管理、客户信息管理等到现在的面向消费者客户的服务系统，十分复杂。系统中的线上销售和售后平台部分是相对比较新、且需求变化特别迅速的部分，也是目前出问题最频繁、收到抱怨最多的部分。

下面我们将从几个方面展开这个话题。

不要从数据库开始建模

传统软件开发中，数据模型被认为是整个系统的核心，业务逻辑仅仅是对数据的CRUD加上简单的计算呈现。有些项目团队的架构评审会花很多时间来讨论系统庞大的ER图（实体关系图）设计。但在微服务架构设计时，ER图并非最佳选择，特别是在服务划分时采用ER图进行建模甚至是十分有害的。

在领域驱动设计的实践中，有一个和ER图建模有些相似的环节，叫做“领域建模”。相比ER图建模通常只有开发人员参与，并从数据表的角度考虑模型的方法，领域建模的过程需要由产品的业务人员和核心开发人员共同参与，先梳理用户场景，然后从业务领域角度，逐步确定场景中的实体、关联和聚合等元素。其中的“实体、关联”与ER图中的“实体、关系”有些相似，但含义并不一致。领域模型中的“实体”本质上是业务场景中需要被持久化存储的对象，但存储方式不一定是数据库，更不一定是关系型数据库，而ER图中的“实体”最终对应的就是关系型数据库的表。领域模型中的“关联”是两个实体在业务上下文之间有业务含义的联系，而ER图中的“关系”只的是两张表之间的一个关联外键。

那么，使用ER图给微服务建模会存在什么问题呢？

首先，ER图设计时假定了使用的是关系型的数据库。微服务的一个特点在于它支持异构架构，系统的不同部分，依据实际需要可选择不同的编程语言、框架以及数据库的类型。关系型数据库采用平面表的结构，如果有两类嵌套关系的对象，只能使用关联表来表达两个实体之间的关系，然后通过复杂的SQL语句在查询时将多个表拼成更大的平面表，最后在业务代码里再分解到各个独立的对象里去。这些单独的表又可能在其他地方与另一个表存在关联查询。这样设计出来的表结构的冗余很低，且使用非常灵活，但正是这种灵活性往导致系统中多个业务逻辑表出现错中缠绕的关系，从而使剥离单独服务进行异构设计变得困难。

其次，ER图还会导致实体相似的不同业务逻辑在设计时被耦合在一起。举一个具体的例子，在汽车代理销售系统中，不同品牌汽车的购买流程后端实际上分别对接的是完全不同的分销渠道系统和逻辑流程，但它们在用户视图上所需要的信息比较一致，因此存储的数据结构也比较相似。这个系统在最初设计时采用了ER图的方式建模，由于ER图模型不关心业务层面上的东西，不同品牌汽车的实体数据看上去都是一种类型的数据，仅仅是一个品牌字段的差异而已，因此被理所当然的设计成了同一张表。上层逻辑实现的时候使用了大量的if-else语句来区分各种品牌的购买流程，结果使得多条完全不同的业务线糅合在同一个上下文里，后来的开发非常容易在这里错改、漏改代码。若当初使用的是领域建模，则不同的购车流程会自然的被划分到各种不同的用户场景，即使它们在数据结构上看起来基本相同，也会被识别为两个独立的上下文，这就会使得未来划分服务时能够更加容易。

最后，ER图设计的架构会使得系统的模块之间倾向于使用数据库集成，而非API集成。在ER图中没有明确划分模块和表的所有权关系，所有的数据表对所有的模块都是可见的，倘若不加额外约束，各个模块便都会轻易的读写其中的内容。数据集成并不会直接导致服务无法拆分，但由于数据的所有权不清晰，十分容易引发的意想不到的状况。还是举销售平台的例子，在ER图建模得到的模型中，有一张与购买记录相关的表。在一次销售业务的代码更新中，对购买结果的增加了字段，在测试过程中没有发现问题，结果上线几天以后，由于售后服务也在修改这个表而导致出现了脏数据，造成难以排查的故障。

当然，我们并非要完全否认ER图建模的价值，只不过通过数据库角度建立模型的过程容易倾向于设计出庞大的单体应用，因而不太适应于服务划分的目的。

端到端的划分服务

在拆服务时要端到端的划分，这是我们在设计微服务时经常听到的一句话。端到端的划分，指的是一个服务负责一个业务领域，这个功能领域的所有逻辑、数据都归它管，这有利于微服务的数据治理。与之相对的是MVC那样的横向服务划分，将所有数据归一块，所有逻辑归另一块，特别是在跨团队管理的情况，横向划分服务会带来十分高昂的协调和联调成本。

道理不必多说，还是讲个例子吧。在汽车销售平台的最初架构中，使用了典型的MVC三层结构，由于人比较多，分成了前台组、后台组，就时不时要出现新开发一个功能，一动底层数据结构，结果上层的另一个不相干页面挂了，一查发现原来那这个页面间接的用了同一个数据模型。比较典型的例子是，有一回负责后台的小组调整了汽车销售服务里面的汽车参数信息相关的对象结构，结果一上线，销售功能正常，试驾服务的页面挂了。原来是试驾功能的前端开发人员在处理汽车信息时候，看到销售模块有现成功能，就直接拿来复用了。这便是服务上下层分团队开发导致的问题。

此外，横向划分服务也不利于系统的开发效率的提升。不同业务服务对功能发布频率的的需求是不一样的，比如试驾平台经常推出新的优惠促销活动，需要尽快进行一次版本更新，于此同时售后服务有一个需要和第三方联调的功能也已经差不多完成并提交到代码仓库了，但由于需要协调第三方系统的时间，最近还不能够上线，此时两边的业务主管就要开掐了。类似这样的情况其实经常发生，通常使用特性分支、特性开关等流程或者技术手段能够规避一部分业务开发进度不一致的风险，但若要从根本上解决这种问题，还是需要端到端的按业务来划分服务。

最后，横向划分模块对于问题的追踪调试也不友好，几乎每次事故调查总是要穿插涉及在几个团队之间不停的协调开会，因为一个完整业务流总是要贯穿前后几个层的功能。

需要指出的是，端到端划分服务并非是说服务与服务之间都是平级的。实际上，服务之间可以再聚合成更高层级的组合服务的，以及在最顶端的API Gateway也可以算是一类服务。只不过，在核心业务层的这些服务，每个都单独提供了某项特定的业务价值。

识别核心业务服务

微服务的架构通常并非是一开始就重头设计出来的，而是先有整块的单体架构，随着业务的复杂度上升，才逐步拆分出来。业务领域建模除了能用来指导适当的服务划分，另一个重要的作用是让工作聚焦到核心的业务服务中。

无论多复杂系统都是为特定业务价值而存在的。在系统的实现中必然会存在与核心业务最相关的部分、辅助核心业务的部分、和非核心业务关系的部分。它们在领域驱动设计的术语中称为“核心域”、“支撑子域”和“通用子域”。在进行领域建模的时候就应该顺便识别出系统里的关键领域。将系统的业务领域罗列出来然后划分出重要性，这件事情听起来似乎是多此一举，甚至有点荒唐，但对于复杂系统，实际去做这件事带来的价值可能远比它看起来更大。

首先，当我们将一个复杂的系统的各种业务仔细清点到台面上以后，得到的列表往往会比许多人最初想象得长得多，它能提醒我们系统的复杂度是否已经过高了。其次，列举业务的过程也是开发者与业务人员沟通的过程，来自不同业务线的代表也许会为某部分业务的价值点发生争执，或是提供一些许多开发人员此前并不了解的细节信息，将这些问题当面讨论清楚并非什么坏事。此外，当我们真的去仔细思考一个业务系统的核心价值时，也许会得出使人意想不到的结果。

继续举例子，在汽车的销售和售后平台中，通过业务建模，可以划分出许多子领域：

在线购车（渠道A）
在线购车（渠道B）
在线购车（渠道C）
试驾预约
售后服务
用户反馈
订单系统
促销活动
车辆市价信息
车辆参数信息
4s店信息
用户信息管理
…

（说明：这里渠道指的是销售平台对接的一个第三方系统，其中每个渠道可以对应多个汽车品牌）

然后我们要从中识别出业务中的核心域。必须强调，服务领域划分仅仅是代表服务对系统关键业务贡献的价值，处于核心域中的那些服务应该是该系统业务成功的主要促成因素，从战略层面讲，企业应该在自己的核心领域上具有一定壁垒优势。经过讨论，开发者和业务人员最终得出让人大跌眼镜的结论，核心域部分的服务只有“试驾预约”和“售后服务”，因为这两项才是该企业最具竞争力的业务。而看起来十分重要的“在线购车”服务，由于并不具有特别的行业竞争优势而被划到了支撑子域中。正确的服务划分定位将对系统未来的发展策略产生积极的影响。

在这个系统中的“车辆市价信息”、“车辆参数信息”、“4s店信息”等服务都被划归到了通用子域。在通用子域中的服务并非最没有价值或是复杂度最低，而只是说明系统在这些服务领域中通常不具优势，因此这部分功能完全可以考虑外包开发或者购买第三方的现成服务。

使用符合业务结构的API

前面介绍业务建模的时候我们强调了使用“API集成”的必要性，以及它的反面形式“数据库集成”所带来的问题。在微服务的架构中，服务的技术选型可能是异构的，API的实现也会各有不同。除了Web应用比较流行的RESTful标准，还有像SOAP、ProtolBuf、MessageQueue等不同的协议与格式标准，它们都可以被作为服务之间通信的API。不同的API设计对服务使用的体验差别会很大，除去技术原因对API协议的倾向性，在设计和评价API方面依然有许多值得注意的地方。

一个好的API设计应该在接口的元数据中向用户提供尽可能多的有意义的业务信息，这里指的元数据包括例如API的名称、参数、标签等等用户在不需要专门查看文档就可以看到的内容。通常在各种不同的API协议里，总会存在一个相似的概念，就是目标路径。比如RESTful的URL地址，ProtolBuf的消息类型嵌套结构，MessageQueue名称里用斜线划分Topic路径的惯例等。以RESTful标准为例，可以试比较下面两种URL地址的差异。

第一种：/users/123/orders/123
第二种：/orders?id=123&user_id=123

显然前一种地址包含的信息更多，它告诉了访问者订单（orders）是属于用户（users）这个实体中的一个子实体，并且包含了一个潜在业务规则，即如果ID为123的这个用户不存在了，那么查询他下面的所有订单信息也是不具有业务意义的。实体之间的嵌套关系可以通过领域建模过程中的聚合识别。当然，这种URL结构有时会导致很长的API路径，但相比它所带来的业务语义，我们认为还是值得的。

类似的语义化例子还有例如：

PUT /services/questions/123
PUT /services/questions/123/comments/123

这是售后服务部分的两个API，分别用来更新提问的内容和提问的评论内容，它们也是按层级组织的。

有些通信协议中还提供了其他可以表明业务语义的元素。比如RESTful中使用GET/POST/PUT操作语义（查询/创建/修改），以及HTTP返回值中的语义信息等。在实际设计API时充分利用这些协议特性，能够使服务变得更加易用。

尾声

在这篇文章里，我们列举了一些微服务划分的实践中常见的反例和值得注意的问题，希望能为读者设计微服务架构时扫清一些阻碍。实际上，本文中提到的许多概念，包括微服务和领域驱动设计，服务的划分都只是其中的冰山一角，在冰水之下还有更多的内容值得我们在实践中去探索。

分享到：

4
顶

1
踩

评论共 0 条请登录后发表评论

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

一文读懂微服务架构设计

一、前言微服务（MicroServices）是一种架构风格，一个大型复杂软件应用由多个微服务和前端展示层组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完...

如何在微服务架构下进行数据设计？

????????关注后回复“进群”，拉你进程序员交流群????????作者：唐建法 &...本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方，旨在帮助大家在构建微服务架构时，提供一个...

为什么选择微服务架构? 微服务架构的10个核心优势总结

为什么选择微服务架构? 微服务架构的10个核心优势总结为什么选择微服务架构? 微服务架构的10个核心优势总结为什么选择微服务架构? 微服务架构的10个核心优势总结为什么选择微服务架构? 微服务架构的10个核心优势 ...

微服务架构介绍

基于DDD（领域驱动设计）的微服务设计实例

DDD（Domain Driven Design，领域驱动设计）是一种行之有效的划分业务领域边界的方法，以帮助完成应用的拆分和微服务的设计。它会按照流程或功能边界分解业务领域，根据业务上下文边界，构建领域模型，并将其作为...

DDD学习笔记---基于DDD的微服务设计实例

项目基本信息项目的目标是实现在线请假和考勤管理。功能描述如下：请假人填写请假单提交审批，根据请假人身份、请假...战略设计采用的方法是事件风暴，包括：产品愿景、场景分析、领域建模和微服务拆分等几个主..

【微服务-架构选型】记录2022年微服务技术架构选型

后端技术栈套用互联网上的一句话，在java领域里面躲不过去的 alibaba ，所以本次微服务架构选型还是基于SpringCloud Alibaba 做为基础。在 Spring Cloud 众多的实现方案中，Spring Cloud Alibaba 凭借其支持组件...

《微服务架构设计模式》第二章

如何定义一个微服务架构呢？文章中介绍了一个三部式流，世界上没有一个完美的机械化方法可以遵循，这个也只是大概方法，现实中还需要不断的迭代。定义系统操作根据功能性需求文档，定义系统可以提供的操作。如FTGO...

微服务架构系列主题：微服务架构概述

微服务（MicroServices）是一种架构风格，一个大型复杂软件应用由多个微服务和前端展示层组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在...

中台架构与实现：基于DDD领域驱动设计和微服务笔记

DDD微服务设计思想，实践方法，理论基础

系统架构演变：SOA、微服务架构的区别和联系

从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？其实生活不止眼前的苟且，...

DDD与微服务架构浅析

我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构，现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯...

java微服务案例分析_多云架构下，JAVA微服务技术选型实例解析

微服务生态微服务生态本质上是一种微服务架构模式的实现，包括微服务开发SDK，以及微服务基础设施。目前比较成熟的 JAVA 微服务生态包括 servicecomb(华为), spring-cloud (Pivotal), dubbo(阿里), tsf(腾讯)等。...

spring微服务架构设计与轻量级微服务架构及最佳部署

1、Eureka用于服务的注册于发现2、Feign支持服务的调用以及均衡负载3、Hystrix处理服务的熔断防止故障扩散4、Spring Cloud Config服务集群配置...负载均衡、反向代理、权限认证的一个API gateway二、要搞定微服务架构...

基于FPGA的四相八拍步进电机控制系统设计：集成交付、正反转、加速减速及调速功能

内容概要：本文详细介绍了基于FPGA的四相八拍步进电机控制系统的开发过程。主要内容包括：1. 使用VHDL和Verilog编写LED显示屏驱动代码，用于显示角度、学号和姓名等信息；2. 实现步进电机的正反转控制，通过状态机管理相序变化；3. 开发加速减速控制模块，确保电机启动和停止时的平稳性；4. 设计调速功能，通过调节脉冲频率实现速度控制。此外，文中还讨论了调试过程中遇到的问题及其解决方案。适合人群：对FPGA开发和步进电机控制感兴趣的电子工程师、嵌入式系统开发者以及相关专业的学生。使用场景及目标：适用于需要高精度运动控制的应用场合，如工业自动化、机器人技术和精密仪器等领域。目标是帮助读者掌握FPGA控制步进电机的基本原理和技术细节。其他说明：文中提供了详细的代码片段和调试经验分享，有助于读者更好地理解和应用所学知识。同时，作者还提到了一些实用技巧，如通过PWM调节实现多级变速，以及如何避免步进电机的共振问题。

Android开发：基于SQLite的日历备忘录记事本项目详解与实现

内容概要：本文详细介绍了基于Android Studio开发的日历备忘录记事本项目，涵盖日历查看、添加备忘录、闹钟提醒和删除备忘录等功能。项目使用SQLite数据库进行数据存储，通过CalendarView、EditText、Button等控件实现用户交互，并利用AlarmManager和PendingIntent实现闹钟提醒功能。此外，项目还包括数据库的设计与管理，如创建DatabaseHelper类来管理数据库操作，确保数据的安全性和完整性。文章还探讨了一些常见的开发技巧和注意事项，如时间戳的使用、手势监听的实现等。适用人群：适用于初学者和有一定经验的Android开发者，尤其是希望深入了解Android开发基础知识和技术细节的人群。使用场景及目标：该项目旨在帮助开发者掌握Android开发的基本技能，包括UI设计、数据库操作、闹钟提醒机制等。通过实际项目练习，开发者能够更好地理解和应用这些技术，提升自己的开发能力。其他说明：文中提到一些进阶任务，如用Room替换SQLite、增加分类标签、实现云端同步等，鼓励开发者进一步扩展和优化项目。同时，项目源码公开，便于学习和参考。

Matlab实现基于SVM-Adaboost支持向量机结合Adaboost集成学习时间序列预测的详细项目实例（含完整的程序，GUI设计和代码详解）

内容概要：本文档详细介绍了一个基于SVM（支持向量机）和Adaboost集成学习的时间序列预测项目。该项目旨在通过结合这两种强大算法，提升时间序列预测的准确性和稳定性。文档涵盖了项目的背景、目标、挑战及其解决方案，重点介绍了模型架构、数据预处理、特征选择、SVM训练、Adaboost集成、预测与误差修正等环节。此外，文档还探讨了模型在金融市场、气象、能源需求、交通流量和医疗健康等多个领域的应用潜力，并提出了未来改进的方向，如引入深度学习、多任务学习、联邦学习等先进技术。适合人群：具备一定机器学习基础的研究人员和工程师，特别是那些从事时间序列预测工作的专业人士。使用场景及目标：①用于金融市场、气象、能源需求、交通流量和医疗健康等领域的复杂时间序列数据预测；②通过结合SVM和Adaboost，提升预测模型的准确性和稳定性；③处理噪声数据，降低计算复杂度，提高模型的泛化能力和实时预测能力。其他说明：文档不仅提供了详细的理论解释，还附有完整的Matlab代码示例和GUI设计指导，帮助读者理解和实践。此外，文档还讨论了模型的部署与应用，包括系统架构设计、实时数据流处理、可视化界面、GPU加速推理等方面的技术细节。

#游戏之追逐奶酪123

威纶通触摸屏配方管理系统解析：宏程序、数据结构与UI设计

内容概要：本文详细介绍了威纶通触摸屏配方管理系统的实现方法及其应用场景。首先，文章讲解了配方管理的基本概念和技术背景，强调了配方管理在工业自动化中的重要性。接着，通过具体的宏程序代码示例，展示了如何实现配方的保存、加载以及安全校验等功能。文中还提到配方数据结构的设计，如使用寄存器地址偏移来确保数据不冲突，并通过CSV文件格式方便地管理和维护配方数据。此外，文章深入探讨了UI设计方面的内容，包括动态图层技术和按钮交互效果的应用，使得用户界面更加友好和直观。最后，作者分享了一些实际项目中的经验和技巧，如文件操作的异常处理和宏指令调试方法。适合人群：从事工业自动化领域的工程师和技术人员，尤其是对触摸屏配方管理系统感兴趣的读者。使用场景及目标：适用于需要频繁切换设备参数的生产环境，如食品加工、注塑成型等行业。通过使用威纶通触摸屏配方管理系统，可以提高工作效率，减少人为错误，同时简化设备调试和维护流程。其他说明：附带的工具包提供了完整的宏指令注释版、图库资源和调试工具，帮助用户更好地理解和应用该系统。

4顶1踩