Go容器化微服务系统实战

课程链接：https://www.itwangzi.cn/3459....

微服务基础介绍步骤0：初窥门径 本节主要内容：本节主要内容 = 微服务 + docker + go-micro 。第一就是介绍微服务，介绍微服务偏概念多一点，原理虽枯燥但也要做好心理准备，主要是讲解微服务如何拆分，以及微服务里有哪些定律；第二就是docker的快速入门以及使用。docker在微服里面占着举足轻重的作用，因为有了docker，微服务才变得容易；第三就是go-micro微服务框架的入门，go-micro微服务框架可以极大的简化微服务的开发。步骤1：小试牛刀 研究微服务是个什么东西。以问题为导向，作为思考的切入点。【学问 = 边学边问】 带着问题来学下面的内容。问题1：是什么是微服务？问题2：为什么需要这个微服务？问题3：微服务里面DDD是什么?步骤2：庖丁解牛 问题1：是什么是微服务？我们先来说一下什么是微服务。微服务，首先它是一种架构模式，这个架构模式是相较于单体应用来说的，相比较我们单体架构，微服务架构更独立，它能够单独的更新和发布，这也是微服务最大的一个特点；【请记死】在微服务里面，它里面的服务仅仅是用于某一个特定的业务功能，这就是我们的微服务。下面我们就用一个图来解释一下：

在这里插入图片描述左边就是我们单体应用，把我们所有的功能还有所有的业务，比如说这个面条，我们把所有的东西放到这一个盘子里面，它就是一个单体应用，更新和发布都是一起的，它是独立不开来的。【把鸡蛋放在同一个篮子里】微服务架构就好比右边，在一个盒子里面放了很多个甜甜圈，我们可以把这个甜甜圈认为是我们的功能模块，我们一个一个的功能模块组合成了我们叫一盒，我们也叫它一个系统，这个盒子就可以是我们的电商系统，这里的一个甜甜圈就可以看成我们一个一个的功能模块。左边是单体应用；右边是微服的架构模式。这样理解是不是很具体化、形象化？大家自己体会一下。【你品，你细品】问题2：为什么需要这个微服务？为什么需要微服务？微服务它的逻辑比较清晰，因为我们前面说的相较于单体应用来说，我们这里的微服务它是把一个一个的功能模块拆分到了我们不同的甜甜圈里，这样就天然的形成了逻辑清晰。【一个萝卜一个坑】比如说我现在要更新一个用户模块的一个功能，我们直接去到用户模块的那个微服务就去修改；微服务可以快速迭代，这里的快速迭代是相较于我们单体应用来说的，单体应用我们是把所有的功能放到一个盘子里面，我们只能在同一个时间点进行集中的测试，然后集中的上线，这会极大的降低了我们迭代的速度。微服务是把它一个一个拆分开来，拆分成一个一个的甜甜圈，一个一个的模块可以单独的发布，这样的极大的可以提升我们的迭代速度，这就是我们为什么需要一个微服务的一个重要的理由，大部分团队里面这个迭代速度占着非常重要的地位，因为公司业务需求迭代也非常的快；我们为什么需要微服务呢？就是在我们一个系统里面它不仅仅是只涉及到一门编程语言，比如说我们这个系统里面它会有我们的AI应用，AI应用目前比较火的语言是Python，但是我们业务需求，业务系统里面它基本上都是用Java写的，我们Python和Java的交互，通常情况下要不就是通过接口，通过接口这种方式，我们发布、包括我们拆分，又回到了单体应用那种场景下去了。那么我们用了微服务以后，我们完全可以把我们的Java，还有我们的Python很友好的结合起来，【当Python的灵活遇到Java的壮实，让胶水牢牢粘住我们的后端】 我们用了微服务以后，这样就可以完美的屏蔽了语言的差异，这也是我们为什么需要微服务的一个特点。那么下面我们再来说一下微服务与DDD。DDD是什么？领域驱动设计【Domain Driven Design】 它是一个简称，全称是领域驱动设计。在微服务里这个领域驱动设计是用来干嘛的？我们在微服务的开发的过程呢，划分微服务是一个难点，也是大家经常争论的一个焦点。我们怎么合理的去划分这个微服务，而不是一味的把微服务拆分成一个微小的服务，不是通过我们代码量来进行拆分，如果是仅仅通过代码行数来拆分我们的微服务，你做到最后你会发现这是一个灾难性的决定，所以我们要合理的拆分我们的微服务，我们合理拆分微服就会用到这个领域驱动设计，下面就是着重的介绍领域驱动设计。我们还要说到一点就是有一个定律是康威定律，你又有疑问了，康威定律又是什么呢？康威定律就是我们系统的架构受制于我们产生这个系统组织架构，通俗一点来讲，就是你的组织架构和你的微服务拆分的这些模块一一对应，这样才能避免我们沟通成本逐步的增加。这个定律就是康威定律。下面我们再来详细的说一下DDD的作用。真正决定软件架构复杂性的是设计方法，就是你软件特别复杂，其实它不是技术复杂，而是你的设计方法复杂了，我们这里的DDD有助于指导我们确定系统的边界，能够让我们聚焦在系统的核心元素之上。有了前两个【确定系统边界+聚焦核心元素】就会帮助我们拆分系统。这是DDD的三个主要的作用，还有一个总结的方法。真正决定软件架构复杂性的是设计方法，而不是我们系统本身，不是我们技术复杂，技术当然它也会有一个复杂性，但是它的复杂性是我们通过学习，通过训练可以掌握的，我们软件的复杂性通常是因为我们设计方法导致的。接下来介绍DDD的一些基本概念。DDD全称叫做领域驱动设计。领域：有范围的界限，有边界的。【隔行如隔山】在领域里面还有一个核心概念就是核心领域：核心领域代表的就是业务系统的核心价值，还有一个通用子域，通用子域提供了我们通用的服务，还有一个支撑子域，支撑子域就是我们业务系统的某一个重要的服务，这几个概念里面大家可能非常直观的能感觉到 领域就是界限，但是核心领域、通用子域和支撑子域又是什么东西呢？下面通过例子给大家来介绍一下。电商它是一个领域，我们就可以理解为它是一个大的界限，有边界的，有范围的界限。其中的子域：有我们的商品子域、用户子域、销售子域、订单子域等等，这是它的一个子域。核心子域：电商系统的销售子域就是我们的核心子域；支撑子域：就是除去销售子域以外的就是支撑子域。在电商系统里面通用子域又是什么东西呢？通用子域就是我们短信、邮件（用于通知）。我们刚才举了一个电商的例子，对领域、核心领域、通用子域，还有支撑子域这些词汇做了简单的理解。我们有了领域这个概念，我们还有一个界限上下文，界限上下文又是什么？它可以说是我们语文中的语境的意思，比如说我们经常说的一个段子，我想静静，第一，这个句子表达就是我想静一静的意思，但是我们把它换一个角度，换一个语境来讲的话，静静是谁？就知道我们语境它很奇妙。我们这里的界限上下文也是语境的意思，只是它在DDD领域驱动设计里面，它叫界限上下文，我们怎么用界限上下文的方式？就是领域+界限上下文。我们有了领域以后，界限上下文又有什么用？虽然界限上下文也有划分的功能，也有区分的功能，它最主要的目的是在于控制边界，比如说我在领域里面，比如领域是我想静静，我要控制这个边界，我不能把语境表示成静静是谁，而是我想表达我想静一静，就是我们要用到界限上下文。界限上下文的作用：在于如何控制边界而非如何划分边界。另外在DDD里面还有一个常用的概念，就是领域模型，我们前面说了领域、界限上下文。领域模型对我们软件设计是非常重要的，它是要解决问题抽象的一种表达，就是你要解决什么问题，你先把它抽象出来，就是领域模型，但是领域模型有多种抽象的模式。领域我们可以简单的反映我们业务上需要解决的一个问题，比如电商领域需要解决的一个问题，我们销的销售子域要解决销售一些问题，那么这个模型就是针对我们该问题提出的解决方案。理解领域模型：领域模型是对软件系统中要解决的问题的抽象表达。领域：是我们业务上要解决的问题。模型：是我们针对该问题提出的解决方案。接下来我们再来说一下这个DDD领域的4层架构：

在这里插入图片描述这个4层架构是非常经典的一个架构：Interface我们也通常叫它User Interface【即UI，用户接口，展示给用户看的东西】，就是我们用户的界面层，表示的是面向用户展示的一层；应用层就是表示我们如何去接收用户，如何分配这个工作，如何让它们协调的进行合作；领域层主要是我们业务的状态，业务的信息以及我们的业务规则，主要是在领域层。基础设施层就是我们通用的一些基础设施，比如说我们的中间件，还有我们的云设施等等。领域在微服务里面是一种典型的就是我们精简的4层架构，那么我们在微服务里面拆分使用到的是什么呢？根据4层架构我们再继续拆分：

在这里插入图片描述继续拆分微服务里面的架构，第一，就是我们前端的应用，前端应用可能是用Vue写的，可能是用React写的，可能是html + css + js写的，写完了以后它会调用我们的接口，它跟后台进行交互的时候会调用接口，调用接口的时候它会调用API网关，【为什么调用网关？因为要解决网络互通的问题，通俗的说就是能ping通】网关就是我们的基础设施。Interface会把这些东西转发到我们的接口层，接口层转发完了以后，它会有一个应用层，我们会把应用层一些应用、一些逻辑的组织方式，放到我们应用层里面，然后应用层再调用领域服务。在领域层里面有一些领域的服务，我们在领域层进一步调用我们的基础设施，比如说我们的MySQL，Redis。这些调用在微服务架构里面的主要拆分下来就是这样的一个过程。前面我们讲了微服务DDD，然后微服务是什么，还有我们为什么需要微服务？我们讲了那么一大堆，目的就是给大家来建立一套微服务的认知，告诉大家微服务是什么？是什么知道了以后我们再回到微服的设计原则。在我们设计的时候遵循一些原则，我们在设计微服务的时候，要遵循领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。数据驱动设计是什么意思？举个例子，就是我们一个系统下来，我们把模块拆分完了，然后大家就开始需求分析，分析完了以后，第一，大家通常做的就是去设计数据库，设计数据表，然后拆分了哪些字段，这就是典型的数据驱动设计。一开始是非常快，但是你会发现到后面维护的时候，你要不就是拆表，要不就是又加表加表字段，就非常的麻烦，这就是典型的数据驱动设计。界面驱动设计就是我们通过界面上缺什么就设计什么。微服的设计原则，就是要有边界清晰的微服务，而不是小单体。边界清晰的服务也是非常容易理解，就是你这个微服务该做什么，这个服务不该做什么要知道，而不是一味的追求，比如说我们的user模块，你又把订单模块放到里面了，这个服务的边界就不是非常的清晰。还有就是要有职能清晰的分层，而不是什么都放到篮子里。职能清晰的分层，前面也讲了微服务的架构层级，经典的4层架构。我们有的时候设计系统的时候，有时为了方便，就是把所有的东西都写在一起，比如说我们设计一个接口层，然后设计一个应用层，然后设计一个逻辑处理层，一旦这个层级多了，就会感觉特别麻烦。前期确实比较麻烦，但是到后期更改和维护的时候是特别方便的，我们微服务里面同样要遵守我们清晰的分层。接着要做自己能hold住的微服务，而不是过度拆分微服务。【为了拆而拆】怎么说？维护过度的拆分必然会带来我们软件维护成本上的上升，因为你这个服务多了呀，你维护每个环节、每个服务之间你会有一个成本的上升，比如说我们的集成成本、运营成本以及我们的监控和定位问题的成本，尤其我们排查问题，还有测试成本，微服务多了以后时间成本会指数级的增加。企业转型中很难短时间内提升我们这些能力，如果我们一些团队里面不具备这些能力，就很难hold住这些细微的微服务。当我们把微服务的设计好，即定义好了微服务边界以后，对服务做尽可能少的拆分过细，你把订单的保存状态也拆成一个微服务，那就过细了，所以我们要做自己的hold住的微服务，根据你公司的目前现状，目前的人力，逐级的去拆分我们的微服务