共计 4818 个字符，预计需要花费 13 分钟才能阅读完成。
课程链接：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 住的微服务，依据你公司的目前现状，目前的人力，逐级的去拆分咱们的微服务
