xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-09-17 08:46:40 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
master
learn.lianglianglee.com/专栏/DDD 微服务落地实战/10 微服务落地的技术实践.md.html
周伟 0f006e4e9b add
2022-05-11 18:57:05 +08:00

681 lines
24 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
<link rel="icon" href="/static/favicon.png">
<title>10 微服务落地的技术实践.md.html</title>
<!-- Spectre.css framework -->
<link rel="stylesheet" href="/static/index.css">
<!-- theme css & js -->
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
<div class="book-brand">
<a href="/">
<img src="/static/favicon.png">
<span>技术文章摘抄</span>
</a>
</div>
<div class="book-menu uncollapsible">
<ul class="uncollapsible">
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/DDD 微服务落地实战/00 开篇词 让我们把 DDD 的思想真正落地.md.html">00 开篇词 让我们把 DDD 的思想真正落地.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/01 DDD ：杜绝软件退化的利器.md.html">01 DDD ：杜绝软件退化的利器.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/02 以电商支付功能为例演练 DDD.md.html">02 以电商支付功能为例演练 DDD.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/03 DDD 是如何落地到数据库设计的？.md.html">03 DDD 是如何落地到数据库设计的？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/04 领域模型是如何指导程序设计的？.md.html">04 领域模型是如何指导程序设计的？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/05 聚合、仓库与工厂：傻傻分不清楚.md.html">05 聚合、仓库与工厂：傻傻分不清楚.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/06 限界上下文：冲破微服务设计困局的利器.md.html">06 限界上下文：冲破微服务设计困局的利器.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/07 在线订餐场景中是如何开事件风暴会议的？.md.html">07 在线订餐场景中是如何开事件风暴会议的？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/08 DDD 是如何解决微服务拆分难题的？.md.html">08 DDD 是如何解决微服务拆分难题的？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/09 DDD 是如何落地微服务设计实现的？.md.html">09 DDD 是如何落地微服务设计实现的？.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/DDD 微服务落地实战/10 微服务落地的技术实践.md.html">10 微服务落地的技术实践.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/11 解决技术改造困局的钥匙：整洁架构.md.html">11 解决技术改造困局的钥匙：整洁架构.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/12 如何设计支持快速交付的技术中台战略？.md.html">12 如何设计支持快速交付的技术中台战略？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/13 如何实现支持快速交付的技术中台设计？.md.html">13 如何实现支持快速交付的技术中台设计？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/14 如何设计支持 DDD 的技术中台？.md.html">14 如何设计支持 DDD 的技术中台？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/15 如何设计支持微服务的技术中台？.md.html">15 如何设计支持微服务的技术中台？.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/16 基于 DDD 的代码设计演示（含 DDD 的技术中台设计）.md.html">16 基于 DDD 的代码设计演示（含 DDD 的技术中台设计）.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/17 基于 DDD 的微服务设计演示（含支持微服务的 DDD 技术中台设计）.md.html">17 基于 DDD 的微服务设计演示（含支持微服务的 DDD 技术中台设计）.md.html</a>
</li>
<li>
<a href="/专栏/DDD 微服务落地实战/18 基于事件溯源的设计开发.md.html">18 基于事件溯源的设计开发.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
let sidebar = document.querySelector('.book-sidebar')
let content = document.querySelector('.off-canvas-content')
if (sidebar_toggle.classList.contains('extend')) { // show
sidebar_toggle.classList.remove('extend')
sidebar.classList.remove('hide')
content.classList.remove('extend')
} else { // hide
sidebar_toggle.classList.add('extend')
sidebar.classList.add('hide')
content.classList.add('extend')
}
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.add('show')
overlay.classList.add('show')
}
function hide_canvas() {
let sidebar = document.querySelector('.book-sidebar')
let overlay = document.querySelector('.off-canvas-overlay')
sidebar.classList.remove('show')
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
<div class="column col-12 col-lg-12">
<div class="book-navbar">
<!-- For Responsive Layout -->
<header class="navbar">
<section class="navbar-section">
<a onclick="open_sidebar()">
<i class="icon icon-menu"></i>
</a>
</section>
</header>
</div>
<div class="book-content" style="max-width: 960px; margin: 0 auto;
overflow-x: auto;
overflow-y: hidden;">
<div class="book-post">
<p id="tip" align="center"></p>
<div><h1>10 微服务落地的技术实践</h1>
<p>如今，做一个优秀的程序员越来越难。激烈的市场竞争、互联网快速的迭代、软件系统规模化发展，无疑都大大增加了软件设计的难度。因此，对于架构师的能力要求也越来越高，就像我的一本书里写道的：</p>
<blockquote>
<p>作为顶级架构师应当具备这样两个核心能力：
（1）能够将业务转换为技术；
（2）能合理利用技术支撑业务。</p>
</blockquote>
<p>“不想当将军的士兵不是好士兵”，因此作为普通开发人员的你，也应当树立成为顶级架构师的目标，并不断努力。</p>
<p><strong>能够将业务转换为技术</strong>，意味着需要将更多的精力放到对业务的理解中。技术本身并不能产生价值，你必须具备超强的业务落地能力，能够将用户的业务需求落地到技术方案，开发出用户乐于使用的产品和功能，用户才能为之买单，企业才能挣钱。具备这样的能力，才能够强力地帮助企业产生效益，才能体现你的价值。学习 DDD 就能让你掌握快速学习业务领域知识的能力。</p>
<p><strong>能合理利用技术支撑业务</strong>，意味着你必须具备广博的知识与开阔的视野，能将用户的业务痛点，快速落地形成合理的，甚至是最优的技术方案。做出用户需要的功能，让用户为之买单，从而为企业产生效益。然而，如今是一个技术快速更迭的时代，各种高新技术层出不穷。每次新产品的开发不是将原有的技术拿来炒冷饭，而是运用更多的新技术解决新问题，让产品更有竞争力与生命力。因此，你必须有广博的技术知识与超强的技术落地能力。</p>
<p>上一讲谈到 DDD 落地微服务的分析设计过程，然后将这些设计最终落实到每个微服务的设计开发中。微服务的落地其实并没有那么简单，需要解决诸多设计与实现的技术难题，这一讲我们就来探讨一下吧。</p>
<h3>如何发挥微服务的优势</h3>
<p>微服务也不是银弹，它有很多的“坑”。开篇词中提到，当我们将一个庞大的业务系统拆分为一个个简单的微服务时，就是希望通过合理的微服务设计，尽量让每次的需求变更都交给某个小团队独立完成，让需求变更落到某个微服务上进行变更。唯有这样，每次变更只需独立地修改这个微服务，独立打包、独立升级，新需求就实现啦，才能发挥微服务的优势。</p>
<p><img src="assets/CgqCHl_YfiGANvdnAAB4Gw-K8Ng757.png" alt="image.png" /></p>
<p>然而，过去很多系统都是这样设计的（如上图所示），多个模块都需要读取商品信息表，因此都通过 JDBC 直接读取。现在要转型微服务了，起初采用<strong>数据共享</strong>的微服务设计，就是数据库不变，然后简单粗暴地直接按照功能模块进行微服务拆分。这时，多个微服务都需要读取商品信息表，都通过 SQL 直接访问。这样的设计，一旦商品信息表发生变更，那么多个微服务都需要变更。这样的设计就使得微服务的<strong>变更与发布变得复杂</strong>，微服务的<strong>优势无法发挥</strong>。</p>
<p><img src="assets/CgqCHl_YfjCAZKv9AABt2_Tef90440.png" alt="image" /></p>
<p>通过前面 DDD 的指导，是希望做“小而专”的微服务设计。按照这样的思路设计微服务，对商品信息表的读写只有“商品维护”微服务。当其他微服务需要读写商品信息时，就不能直接读取商品信息表，而是通过 API 接口去调用“商品维护”微服务。这样，日后因商品信息变更而修改的代码就只限于“商品维护”微服务。只要“商品维护”微服务对外的 API 接口不变，这个变更则与其他微服务无关。只有这样的设计，才能真正发挥微服务的优势。</p>
<p>为了规范“小而专”的微服务设计，在微服务转型之初，先按照 DDD 对数据库表按照用户权限进行划分。每个微服务只能通过自己的账号访问自己的表。当需要访问其他的表时，只能通过接口访问相应的微服务。这样的划分，就为日后真正的数据库拆分做好了准备，微服务转型将更加平稳。</p>
<h3>怎样提供微服务接口</h3>
<p>因此，微服务的设计彼此之间不是孤立的，它们需要相互调用接口实现高内聚。然而，当一个微服务团队向另一个微服务团队提出接口调用需求时，另一个微服务团队该如何设计呢？</p>
<p>首先第一个问题，当多个团队都在向你提出 API 接口时，<strong>你怎么提供接口</strong>。如果每个团队给你提需求，你就必须要做一个新接口，那么你的微服务将变得非常不稳定。因此，当多个团队向你提需求时，必须要对这些接口进行规划，通过复用用尽可能少的接口满足他们的需求；当有新的接口提出时，要尽量通过现有接口解决问题。这样做，你就能用更低的维护成本，更好地维护自己的微服务。</p>
<p>接着，当调用方需要接口变更时怎么办？变更现有接口应当尽可能<strong>向前兼容</strong>，即接口的名称与参数都不变，只是在内部增加新的功能。这样做是为了不影响其他微服务的调用。如果确实需要更改现有的接口怎么办？<strong>宁愿增加一个新的接口也最好不要去变更原有的接口</strong>。</p>
<p><img src="assets/Ciqc1F_YfkCAJF6yAAEHWZqB_VU738.png" alt="DDD 10--金句.png" /></p>
<p>此外，调用双方传递的值对象需要完全一致吗？当然不用。当被调方因为某些变更对值对象增加了字段，而这些字段调用方不使用时，那么调用方不需要跟着变更值对象。因为微服务间的调用是采用RESTful 接口，以 Json 的形成传递数据，是一种<strong>松耦合的调用</strong>。因此调用双方的值对象可以不一致，从而降低了需求变更的微服务更新范围。</p>
<p>最后，调用方如何调用接口呢？这里分为<strong>同步调用</strong>与<strong>异步调用</strong>。</p>
<ul>
<li>第 09 讲谈到“用户接单 Service”在完成下单以后，用消息队列通知“饭店接单 Service”，就是异步调用。</li>
<li>接着，“用户接单Service”常常要查找用户表信息，但前面说了，它没有查询用户表权限，因为用户表在“用户注册”微服务中。这时，“用户接单 Service”通过同步调用“用户注册 Service”的相关接口。</li>
</ul>
<p>具体设计实现上，就是在“用户接单”微服务的本地，增加一个“用户注册 Service”的 feign 接口。这样，“用户接单 Service”就像本地调用一样调用“用户注册 Service”，再通过这个 feign 接口实现远程调用。这样的设计叫作“<strong>防腐层</strong>”的设计。如下图所示：</p>
<p><img src="assets/Ciqc1F_PHxGAKZQJAADJmVVEwcE418.png" alt="Drawing 2.png" /></p>
<p>微服务的拆分与防腐层的设计图</p>
<p>譬如，大家想象这样一个场景。过去，“用户注册 Service”是在“用户下单”微服务中的。后来，随着微服务设计的不断深入，需要将“用户注册 Service”拆分到另外一个微服务中。这时，“用户下单Service”与“取消订单 Service”，以及其他对“用户注册 Service”的调用都会报错，都需要修改，维护成本就很高。这时，在微服务的本地放一个“用户注册 Service”的 feign 接口，那么其他的 Service 都不需要修改了，维护成本将得以降低。这就是“防腐层”的作用，即<strong>接口变更时降低维护成本</strong>。</p>
<h3>去中心化的数据管理</h3>
<p>按照前面 DDD 的设计，已经将数据库按照微服务划分为用户库、下单库、接单库、派送库与饭店库。这时候，如何来落地这些数据库的设计呢？微服务系统最大的设计难题就是要<strong>面对互联网的高并发与大数据</strong>。因此，<strong>可以按照</strong>“<strong>去中心化数据管理</strong>”<strong>的思想</strong>，<strong>根据数据量与用户访问特点</strong>，<strong>选用不同的数据存储方案存储数据</strong>：</p>
<ul>
<li>微服务“用户注册”与“饭店管理”分别对应的用户库与饭店库，它们的共同特点是<strong>数据量小但频繁读取</strong>，可以选用小型的 MySQL 数据库并在前面架设 Redis 来提高查询性能；</li>
<li>微服务“用户下单”“饭店接单”“骑士派送”分别对应的下单库、接单库、派送库，其特点是<strong>数据量大并且高并发写</strong>，选用一个数据库显然扛不住这样的压力，因此可以选用了 TiDB 这样的 NewSQL 数据库进行分布式存储，将数据压力分散到多个数据节点中，从而解决 I/O 瓶颈；</li>
<li>微服务“经营分析”与“订单查询”这样的查询分析业务，则选用 NoSQL 数据库或大数据平台，通过读写分离将生产库上的数据同步过来进行分布式存储，然后经过一系列的预处理，就能应对海量历史数据的决策分析与秒级查询。</li>
</ul>
<p><strong>基于以上这些设计</strong>，<strong>就能完美地应对互联网应用的高并发与大数据</strong>，<strong>有效提高系统性能</strong>。设计如下图所示：</p>
<p><img src="assets/CgqCHl_PHyaAXlokAAPzBHQJW_U719.png" alt="Drawing 3.png" /></p>
<p>在线订餐系统的去中心化数据管理图</p>
<h3>数据关联查询的难题</h3>
<p>此外，各个微服务在业务进行过程需要进行的各种查询，由于数据库的拆分，就不能像以前那样进行 join 操作了，而是通过接口调用的方式进行数据补填。比如“用户下单”“饭店接单”“骑士派送”等微服务，由于数据库的拆分，它们已经没有访问用户表与饭店表的权限，就不能像以往那样进行 join 操作了。这时，需要重构查询的过程。如下图所示：</p>
<p><img src="assets/CgqCHl_YfnGAdDcRAABzT74i0y8432.png" alt="image" /></p>
<p>查询的过程分为 2 个步骤。</p>
<ol>
<li>查询订单数据，但不执行 join 操作。这样的查询结果可能有 1 万条，但通过翻页，返回给微服务的只是那一页的 20 条数据。</li>
<li>再通过调用“用户注册”与“饭店管理”微服务的相关接口，实现对用户与饭店数据的补填。</li>
</ol>
<p><strong>这种方式</strong>，<strong>既解决了跨库关联查询的问题</strong>，<strong>又提高了海量数据下的查询效率</strong>。注意，传统的数据库设计之所以在数据量越来越大时，查询速度越来越慢，就是因为<strong>存在 join 操作</strong>。因而，在面对海量数据的查询时，干掉 join 操作，改为分页后的数据补填，就能有效地提高查询性能。</p>
<p>然而，在查询订单时，如果要通过用户姓名、联系电话进行过滤，然后再查询时，又该如何设计呢？<strong>这里千万不能先过滤用户数据</strong>，<strong>再去查询订单</strong>，<strong>这是一个非常糟糕的设计</strong>。我们过去的数据库设计采用的都是<strong>3NF（第 3 范式）</strong>，它能够帮助我们<strong>减少数据冗余</strong>，然而却带来了<strong>频繁的 join 操作</strong>，<strong>降低了查询性能</strong>。因此，为了提升海量数据的查询性能，适当增加冗余，即在订单表中增加用户姓名、联系电话等字段。这样，在查询时直接过滤订单表就好了，查询性能就得到了提高。</p>
<p>最后，当系统要在某些查询模块进行订单查询时，可能对各个字段都需要进行过滤查询。<strong>这时就不再采用数据补填的方式</strong>，<strong>而是利用 NoSQL 的特性</strong>，<strong>采用“宽表”的设计</strong>。按照这种设计思路，当系统通过读写分离从生产库批量导入查询库时，提前进行 join 操作，然后将 join 以后的数据，直接写入查询库的一个表中。由于这个表比一般的表字段更多，因此被称为“宽表”。</p>
<p>由于 NoSQL 独有的特性，为空的字段是不占用空间的，因此字段再多都不影响查询性能。这样，在日后的查询时，就不再需要 join 操作，而是直接在这个单表中进行各种过滤、各种查询，从而在海量历史数据中实现秒级查询。因此，“订单查询”微服务在数据库设计时，就可以通过NoSQL 数据库建立宽表，从而实现高效的数据查询。</p>
<h3>总结</h3>
<p>基于 DDD 的微服务设计，既强调对业务的分析理解，又强调对业务的技术落地。只有把这两个事情都做好了，产品才能被用户认可，我们才能体现出价值。在这个过程中，微服务间要通过 feign 接口相互调用，数据要通过补填关联查询。此外，还有聚合的实现、仓库和工厂的设计。所有这些内容都需要在 DDD 设计思想的基础上，落地实现。</p>
<p>然而，如果每个模块都要反复地写代码去实现这些功能，DDD 的设计将显得异常烦琐，因此迫切需要有一个既支持 DDD，又支持微服务的技术中台，封装这些代码，简化微服务的设计。</p>
<p>下一讲我将开始讲解支持 DDD 与微服务的技术中台的设计实践。</p>
</div>
</div>
<div>
<div style="float: left">
<a href="/专栏/DDD 微服务落地实战/09 DDD 是如何落地微服务设计实现的？.md.html">上一页</a>
</div>
<div style="float: right">
<a href="/专栏/DDD 微服务落地实战/11 解决技术改造困局的钥匙：整洁架构.md.html">下一页</a>
</div>
</div>
</div>
</div>
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70996ec00fb23d60","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
</body>
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
var path = window.location.pathname
var cookie = getCookie("lastPath");
console.log(path)
if (path.replace("/", "") === "") {
if (cookie.replace("/", "") !== "") {
console.log(cookie)
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
}
} else {
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
var expires = "expires=" + d.toGMTString();
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
var ca = document.cookie.split(';');
for (var i = 0; i < ca.length; i++) {
var c = ca[i].trim();
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
}
return "";
}
</script>
</html>
Reference in New Issue View Git Blame Copy Permalink