文档介绍：微服务设计案例分析
 
 
作者：汪照辉 王作敬
汪照辉个人页面
跟很多人也讨论过微服务的设计方法问题，大部分人都说是用领域驱动设计方法。不过个人觉得领域驱动设计并不是很好的方法，其概念过于复杂，实际领域界限划分又没有让普通的厂商做做运维打打杂就行。
二、 主数据实体提取和微服务拆分
业务流程、数据流程分析我们就不在此讨论了。客户是所有业务中最重要最基础的主数据，这里我们直接提取了业务中的主数据实体客户，其包括机构客户、个人客户、潜在客户等。而潜在客户可能并没有证券账户，并不是正式客户，潜在客户又有机构客户和个人客户，也就是潜在机构客户、潜在个人客户。很多人关注微服务拆分，那客户有这么多信息，是否该拆分？该怎么拆分？
但从微服务架构来说，客户可以是个微服务，提供客户信息的增删改查操作接口。但从业务角度来说，机构客户和个人客户属性差别很大，因此可以把机构客户和个人客户分拆为两个的微服务：机构客户微服务和个人客户微服务，这也是企业机构服务和零售服务发展的要求，特别是证券业务客户机构化发展的要求。而不管是潜在个人客户或潜在机构客户，只需要一个标志位即可，没必要作为独立的微服务存在。在客户转化时，只需要更新标志位。因此，我们先考虑把客户拆分为两个微服务：机构客户微服务和个人客户微服务。
从客户类型我们可以划分为两个微服务，但客户除了标志客户身份的基本信息外，还有其他信息，如地址信息、联系信息、关联信息、来源信息、常用设备信息、开通业务信息等等，是都要拆分为独立的微服务吗？我们认为这些信息是和客户紧密耦合的，宜划分在一个微服务内。当然也可以根据业务流程实现要求和数据量等指标划分为多个微服务，重点在于方便、简化业务应用的逻辑实现。
三、 微服务数据来源和存储
微服务从业务角度划分之后，只能算初步设计，还需要考虑微服务“数据来源”和微服务“数据存储”，也就是微服务数据的“读”和“写”。通常基本的微服务实体数据来自于一个数据库表。这相对来说是比较简单的。但大多数业务逻辑不会这么简单，数据可能来自多个数据库表，还有一些数据往往需要经过一些处理，比如来自于大数据平台或者数据仓库，或者别的微服务。我们认为这是微服务设计很关键的问题，不是一个mybatis就ok了。
微服务拆分很多时候需要考虑数据量、并发量、最大响应延迟、部署方式、部署地点等需求。这些因素会影响到数据物理模型的设计，比如数据表是否需要分区，数据是否需要分库，数据请求是否需要分区域处理，哪种数据物理模型设计能满足请求响应延迟，微服务访问数据库能够支持弹性伸缩等等。因此我们觉得微服务设计就不像SOA ESB服务那样仅仅考虑封装功能，更要考虑重构数据模型和数据存储结构。
机构客户和个人客户微服务确定之后，需要考虑微服务的数据物理模型设计，也要依据业务梳理情况和数据预测情况来确定，比如客户当前数据量和日增长量、月增长量、年整长量等，来确定物理数据模型设计。比如客户量在百万级别、千万级别和在亿万级别数据存储方式肯定要不一样。对于券商来说，客户量通常在百万到千万级别，因此通常通过数据表分区就可以满足业务需求。数据库表分区主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间，通常为了提升性能和简化数据管理。比如日志数据，通常量比较大，就可以考虑表分区，每日的日志数据存储