王作敬
作者王作敬2019-02-12 10:09
管理信息系统总监, 银河证券

微服务设计案例分析

字数 3383阅读 1919评论 0赞 4

作者:汪照辉 王作敬
汪照辉个人页面


跟很多人也讨论过微服务的设计方法问题,大部分人都说是用领域驱动设计方法。不过个人觉得领域驱动设计并不是很好的方法,其概念过于复杂,实际领域界限划分又没有明确的标准,完全靠经验,糅合了众多设计和实现概念,没有深厚的设计和编程经验想短期内弄明白并非易事。我们曾经建议在微服务设计过程中采用主数据设计的方式,首先梳理业务流程和数据流程,提取主数据实体,比如主数据实体有客户、账户、资金、产品(股票、期货、基金、债券、贵金属等)、积分等,简单的每个主数据实体可以作为一个微服务,不过实际情况,也可能一个主数据实体又可以分拆为多个微服务,或者多个主数据实体合并为一个微服务,这要基于实际的数据量、实体间关系、访问量、性能要求、延迟要求等来决定,直接从业务入手,不考虑那么多繁琐的技术概念。今天我们尝试用简单的例子来分析下如何实现微服务设计。

一、 问题提出

证券公司业务繁多,客户类型有很多种,比如机构客户、个人客户、潜在客户等。客户数据通常根据业务系统存储在不同的数据库中。这些数据后同步到数据仓库,按照数据仓库中数客户模型保存使用数据。我们就拿客户设计实现微服务来简单讨论下方法和步骤。
按照业务流程和数据流程以及原数据模型设计,客户包含客户基本信息、个人客户信息、机构客户信息、客户地址信息、客户联系信息、客户关联信息、客户证券代码信息、潜在客户信息、客户识别信息、客户注册信息、客户设备信息、客户权限信息、客户扩展信息、客户来源信息等等。这些数据分别存放于不同的表中。原来的系统数据模型设计是把潜在客户作为独立的一个实体,潜在客户转化为正式客户之后需要经过复杂的数据迁移操作。我们也请了一家厂商来帮助我们设计实现微服务,也许是时间紧任务重,也许是不会、不懂、不愿懂,把所有客户相关的信息打包成一个微服务,数据模型几乎不变,搬到一个独立的数据库中,数据又重新copy了一份,结果又需要多维护数据库和实现数据同步机制。在讨论改造优化过程中他们还觉得粒度太细,实现起来不方便。我们一再强调基础平台外购,业务应用自研的模式也是基于此。不说厂商的能力不足,厂商和我们的目标都不一致,怎么可能把事情做好?因此,对于那些致力于微服务架构的企业,要么投入足够的资金选择好的厂商,要么选择自己来实现微服务设计,让普通的厂商做做运维打打杂就行。

二、 主数据实体提取和微服务拆分

业务流程、数据流程分析我们就不在此讨论了。客户是所有业务中最重要最基础的主数据,这里我们直接提取了业务中的主数据实体客户,其包括机构客户、个人客户、潜在客户等。而潜在客户可能并没有证券账户,并不是正式客户,潜在客户又有机构客户和个人客户,也就是潜在机构客户、潜在个人客户。很多人关注微服务拆分,那客户有这么多信息,是否该拆分?该怎么拆分?
但从微服务架构来说,客户可以是个微服务,提供客户信息的增删改查操作接口。但从业务角度来说,机构客户和个人客户属性差别很大,因此可以把机构客户和个人客户分拆为两个的微服务:机构客户微服务和个人客户微服务,这也是企业机构服务和零售服务发展的要求,特别是证券业务客户机构化发展的要求。而不管是潜在个人客户或潜在机构客户,只需要一个标志位即可,没必要作为独立的微服务存在。在客户转化时,只需要更新标志位。因此,我们先考虑把客户拆分为两个微服务:机构客户微服务和个人客户微服务。
从客户类型我们可以划分为两个微服务,但客户除了标志客户身份的基本信息外,还有其他信息,如地址信息、联系信息、关联信息、来源信息、常用设备信息、开通业务信息等等,是都要拆分为独立的微服务吗?我们认为这些信息是和客户紧密耦合的,宜划分在一个微服务内。当然也可以根据业务流程实现要求和数据量等指标划分为多个微服务,重点在于方便、简化业务应用的逻辑实现。

三、 微服务数据来源和存储

微服务从业务角度划分之后,只能算初步设计,还需要考虑微服务“数据来源”和微服务“数据存储”,也就是微服务数据的“读”和“写”。通常基本的微服务实体数据来自于一个数据库表。这相对来说是比较简单的。但大多数业务逻辑不会这么简单,数据可能来自多个数据库表,还有一些数据往往需要经过一些处理,比如来自于大数据平台或者数据仓库,或者别的微服务。我们认为这是微服务设计很关键的问题,不是一个mybatis就ok了。
微服务拆分很多时候需要考虑数据量、并发量、最大响应延迟、部署方式、部署地点等需求。这些因素会影响到数据物理模型的设计,比如数据表是否需要分区,数据是否需要分库,数据请求是否需要分区域处理,哪种数据物理模型设计能满足请求响应延迟,微服务访问数据库能够支持弹性伸缩等等。因此我们觉得微服务设计就不像SOA ESB服务那样仅仅考虑封装功能,更要考虑重构数据模型和数据存储结构。
机构客户和个人客户微服务确定之后,需要考虑微服务的数据物理模型设计,也要依据业务梳理情况和数据预测情况来确定,比如客户当前数据量和日增长量、月增长量、年整长量等,来确定物理数据模型设计。比如客户量在百万级别、千万级别和在亿万级别数据存储方式肯定要不一样。对于券商来说,客户量通常在百万到千万级别,因此通常通过数据表分区就可以满足业务需求。数据库表分区主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间,通常为了提升性能和简化数据管理。比如日志数据,通常量比较大,就可以考虑表分区,每日的日志数据存储在一个分区中。这样查询特定日期的数据就直接落在某个分区上,大大减少表数据扫描时间;在保留一段时间的数据后,可以把到期的数据转存到数仓或大数据平台,也可以按分区来处理。
客户是来自全国各地甚至是全球各地,地域的远近会造成延迟的不同,在进行一些活动时,会影响到客户的体验。因此一些时候活动是分地域的。微服务需要考虑部署于不同的数据中心以支持不同地域客户的相同体验。这可能需要考虑客户数据分库存放。一个地区数据量比较大的情况下,为了性能也可以考虑分库分表。分库、分表、分区都不应该影响微服务的接口API,只是微服务实现逻辑的差别。

四、 微服务功能分层

微服务数据物理存储模型通常可以快速实现单表的数据服务操作,但一个业务应用可能会涉及很多个基础的数据服务操作,也就是说可能是跨表、跨库的操作,或者数据是从别的平台或别的微服务来的。这让我们觉得微服务设计不是一成不变的,需要根据实际的业务逻辑和数据来源来选择合适的方法。我们也提到过数据可以是主动准备,也可以是被动获取。因此在一个微服务操作涉及多个数据来源时,可能就不是简单的顺序或并发调用,和微服务单一数据来源时的实现方式可能是不一样的。单一数据来源的微服务通常是数据微服务,通常直接和数据库打交道。多个数据来源的微服务通常是业务微服务,可能包含有复杂的业务逻辑实现。因此我们可以将微服务分为数据微服务(原子微服务)和业务微服务(组合微服务)。若干数据微服务和若干业务微服务再编排为业务应用。
比如客户基本信息微服务就是原子微服务,客户全景资产就是业务微服务,资产可能包含现金、股票、基金、贵金属等等,一些是在途的。全景资产有的实现的是T-1日的,无法作到实时全景资产。我们觉得不是技术问题,是架构和设计问题。资产变化时是否能实时知道资产的变化,能否获知变化这个事件,是否有能力对这个事件进行实时处理,这关系到是否有技术能力支撑实时全景资产的实现。这涉及事件处理和复杂事件处理机制,也是我们一直强调的微服务实现不只是考虑http restful,微服务和事件处理密切相关,事件处理机制也是企业微服务技术架构不可或缺的部分。事件处理和复杂事件处理也可以看作是一个微服务组件——事件处理微服务!

五、 微服务调用和协同

上面其实我们已经谈到微服务的协同问题。微服务之间不是简单的你调我,我调你,而是合作协同。就是在你不在时我依然可以提供服务,或者我不可达时你依然可以提供服务。这要求微服务的设计要考虑容错机制。
比如上面我们提到的客户全景资产,如果客户信息不可用或某项资产不可达,也不应该返回错误,而是对该项信息或资产单独处理,自动重试、客户手动刷新、暂不计入或有总额没有明细等。
总的来说,微服务设计不能一根筋,一条路走到黑,需要根据实际的业务逻辑和场景选择合适的实现方法,其重点还在于数据。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

4

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广