微服务的架构设计.docx

微服务的架构设计

近年来，服务化和微服务的架构随着线上业务对响应变化和发布频率要求的不断提高已经变得日益常见。下面yjbys小编为大家准备了关于微服务架构设计的文章，欢迎阅读。 前言 许多企业对微服务思考的关注点也从最初的“该不该用”、“该如何用”逐渐转向“如何评价服务拆分的好坏”、“服务拆分后的数据如何治理”这样更加具体而实际的方面。纵观社区里与微服务有关的话题，既有一些适合大众阅读的概念入门科普文章，也有一些像“架构去中心化”、“消息异步解耦”、“最终一致性补偿”这类专业性的技术讨论，但却很少看到能够比较深入的介绍微服务实施经验，说清楚“什么地方会有什么坑”这类问题的实践性内容。 若将微服务的方方面面铺开，将是一个非常庞大而复杂的知识体系。万事开头难，如何迈出服务划分的第一步是对于那些从未采用过微服务的项目首先要面对的问题。虽然服务的划分本来是一件十分凭借架构师个人经验和对业务理解的主观工作，但其中仍然有些规律可循。根据服务的类型特点，可以有以下几种常见的方式： 1.根据业务进行建模，依据业务领域的边界划分，这也是当下微服务社区十分推崇的领域驱动设计(DomainDrivenDesign，简称DDD)方法; 2.根据资源使用类型划分，这种方式主要使用在对硬件资源需求很高、或对特定硬件类型/区域地址等存在依赖的大型服务系统，例如系统的某些功能非常消耗CPU、或是某些功能必须在有加密狗设备的机器上运行。此时可以依据系统各部分对不同资源的需要作为边界进行最安全的划分，以最大化运行效率; 3.根据数据边界划分，直接从数据表结构或数据源着手，依据数据归属关系界定服务。这种划分方法简单粗暴且能避免数据耦合，但容易导致潜在隐患，甚至可以被认为是一种反模式。仅仅对于强数据驱动的系统，如某些报表系统和多数据源ETL系统等适用，在实际案例中很少见。 从现实上来说，我们平时遇到的绝大部分系统都是需要为特定终端用户群体服务的。因此，采用基于业务领域的建模的方法通常都会是个不错的选择，它也是目前在划分服务问题中的最主流的方法。不过即使有了理论指导的支撑，服务划分里的利弊权衡并不是非黑即白的事情，依然存在不少模棱两可之处，只有在犯下一些错误后才能摸索出适合自己系统的方法。本文将会聚焦在这些点。 没有什么能比一个具体而贴近真实的案例更具有代表性了。因此，我们将剖析一个传统行业企业的线上业务：某汽车产品代理商的线上销售和售后平台，介绍它在微服务转型过程中遇到的种种情况，希望能以此作为前车之鉴，让后来者避开不必要的趟坑。这个案例中讲述的场景原型并非完全来自同一个项目，而是从我们过去一年中所经历的多个项目的实际场景抽取出来的，去除了其中的敏感信息，并添加了基于真实情况的适当演绎，使之更加完整。简单介绍一下案例的背景：这是一家颇具规模的汽车代理商企业，承接多个国际一线品牌汽车的销售和周边资源整合的业务，具有庞大的实体店网点。其线上的IT业务系统已经存在了十余年，提供的功能从最初的进销存管理、客户信息管理等到现在的面向消费者客户的服务系统，十分复杂。系统中的线上销售和售后平台部分是相对比较新、且需求变化特别迅速的部分，也是目前出问题最频繁、收到抱怨最多的部分。 不要从数据库开始建模 传统软件开发中，数据模型被认为是整个系统的核心，业务逻辑仅仅是对数据的CRUD加上简单的计算呈现。有些项目团队的架构评审会花很多时间来讨论系统庞大的ER图(实体关系图)设计。但在微服务架构设计时，ER图并非最佳选择，特别是在服务划分时采用ER图进行建模甚至是十分有害的。 在领域驱动设计的实践中，有一个和ER图建模有些相似的环节，叫做“领域建模”。相比ER图建模通常只有开发人员参与，并从数据表的角度考虑模型的方法，领域建模的过程需要由产品的业务人员和核心开发人员共同参与，先梳理用户场景，然后从业务领域角度，逐步确定场景中的实体、关联和聚合等元素。其中的“实体、关联”与ER图中的“实体、关系”有些相似，但含义并不一致。领域模型中的“实体”本质上是业务场景中需要被持久化存储的对象，但存储方式不一定是数据库，更不一定是关系型数据库，而ER图中的“实体”最终对应的就是关系型数据库的表。领域模型中的“关联”是两个实体在业务上下文之间有业务含义的联系，而ER图中的“关系”只的是两张表之间的一个关联外键。 那么，使用ER图给微服务建模会存在什么问题呢? 首先，ER图设计时假定了使用的是关系型的数据库。微服务的一个特点在于它支持异构架构，系统的不同部分，依据实际需要可选择不同的编程语言、框架以及数据库的类型。关系型数据库采用平面表的结构，如果有两类嵌套关系的对象，只能使用关联表来表达两个实体之间的关系，然后通过复杂的SQL语句在查询时将多个表拼成更大的平面表，最后在业务代码里再分解到各个独立的对象