MINJIEZHOU's Blog

上一次我们通过一张架构图（.Net Core with 微服务 - 架构图）来讲述了微服务的结构，分层等内容。从现在开始我们开始慢慢搭建一个最简单的微服务架构。这次我们先用几个简单的 web api 项目以及 ocelot 网关项目来演示下网关是如何配置，如何工作的。 Ocelot 网关 Ocelot 是使用 asp.net core 开发的一个 api 网关项目。它功能丰富，集成了路由、限流、缓存、聚合等功能。它使用 .net 编写，本质上就是一堆 asp.net core 的中间件，所以它天生对 .net 友好。这些中间件拦截外部的请求，根据路由配置转发到对应的内部服务上，再把内部的返回结果对外暴露。 搭建项目结构 新建一个解决方案，新建几个项目。 api_gateway API网关 hotel_base 酒店基本信息服务 member_center 会员中心服务 ordering 订单服务 [Read More]

上一次我们简单介绍了什么是微服务（.NET Core with 微服务 - 什么是微服务 ）。介绍了微服务的来龙去脉，一些基础性的概念。有大佬在评论区指出说这根本不是微服务。由于本人的能力有限，大概也只能理解到这个层次。先不管它到底是不是微服务吧，既然开篇了，那就硬着头皮把这个系列写完。我想不管是对自己对看官多少还是有点帮助的。 架构图 这篇文章将从一张架构图开始说起（开局一张图，内容全靠凑🤣）。 很多介绍微服务架构的文章画的架构图比这张图复杂的多。我根据自己的理解与实践修改跟精简了一下。 上次评论区说.Net只在标题上出现了一次，那么这次，大概也只会在标题上出现一次🤣。大概从下一篇开始就会正式介绍如何使用 .net core 一步步实现一个最简微服务系统。 下面就开始对照这张架构图进行讲解吧。 基础服务层 基础服务层是一个抽象的概念。我们把提供基础业务处理能力的服务归类到这一层。我们按照模块\领域等概念把服务划分好，最后建成了一个个独立部署的服务。它们提供一些基础的服务功能，对外提供一些api接口。每个服务都有自己独立的数据库，独立的运行时。每个服务都可以根据压力进行伸缩。这一层可以说是微服务架构里最核心的一层。 比如一个酒店管理系统，我们一般可以划分成：“酒店基本信息服务”、“订单服务”、“会员服务”、“支付服务”等等基础服务，每个服务都提供一些api，比如订单服务提供查询下单等服务，支付服务提供微信支付的支付能力等等。 当然如何划分都是似情况而定的，这里只是举个例子。 聚合服务层 我们已经有了基础服务，为什么还会有聚合服务这一层呢。假设现在用户根据订单号查询订单明细的功能。这个功能可能需要涉及到订单基本信息、用户基本信息、会员信息、支付信息、房型信息等多个api。如果有前端直接调用基础服务层，那么可能要发送多次http请求。所以为了效率往往还需要有一个服务来聚合跟适配，合并成一次请求再对前端提供服务，这样对于前端来说效率相对会高一些，开发起来也简单很多。 再比如我们现在的系统往往会接入很多终端，有PC，有APP，有小程序。由于设备的不同，我们对外需要展示的内容也会有差异，我们可以在聚合层进行api的适配跟裁剪，根据不同的设备返回不同的响应。 网关 微服务网关在这个微服务架构中起着至关重要的的地位。从上面的图上可以看到，网关在架构的顶端，是流量的入口。它对每个一个请求进行监控，路由。使每一个合法的请求进入到对应的服务。 因为所有请求都会过网关，所以网关可以做一些全局的工作或者说类似AOP思想里切面的工作。比如认证、授权、限流、过滤等等。一旦网关服务崩溃往往会影响到整个微服务的工作，尽管它内部服务全部正常，但是它可能无法对外提供服务。 正因为网关所在的位置在架构中所承担的功能，所以我们需要网关组件的性能非常高，稳定性非常高。 常用的网关组件有：kong，zuul，Ocelot 等。在 .Net 领域用的比较多的是Ocelot。 微服务相关组件 很多网上的架构图都把微服务相关的这些组件写到业务服务层下面，叫做支撑服务。其实个人是不太认同的。所谓支撑的话可以说是桌子的腿，少了一条桌子就会翻了。事实上我觉得一个完整的微服务不一定非要上全了所有组件。这种都是视情况而定的，没有绝对的说法。比如说不上监控服务，微服务就不能跑了吗？显然不是的。不是说上了这些组件就叫微服务，不上就不是微服务。有了日志聚合、服务发现等等组件是为了更好的实施微服务，但不是必须的，所以我并没有把他们叫做支撑服务。 服务注册发现 在实施微服务之后，我们的调用都变成了服务间的调用。服务间调用需要知道IP、端口等信息。再没有微服务之前，我们的调用信息一般都是写死在调用方的配置文件里（当然这话不绝对，有些公司会把这些信息写到数据库等公共的地方，以方便维护）。又由于业务的复杂，每个服务可能依赖N个其他服务，如果某个服务的IP，端口等信息发生变更，那么所有依赖该服务的服务的配置文件都要去修改，这样显然太麻烦了。有些服务为了负载是有个多个实例的，而且可能是随时会调整实例的数量。如果每次调整实例数量都要去修改其他服务的配置并重启那太麻烦了。 为了解决这个问题，业界就有了服务注册发现组件。 假设我们有服务A需要调用服务B，并且有服务注册发现组件R。整个大致流程将变成大噶3部： 服务B启动向服务R注册自己的信息 服务A从服务R拉取服务B的信息 服务A调用服务B [Read More]

微服务是这几年最流行的架构，说起架构不提微服务都不好意思跟人家打招呼。最近想要再梳理一下关于微服务的知识，并且结合本人的一些实践经验来做一些总结与分享。前面会分享一些概念性的东西，后面也会使用.net来实践，一步步完成一个简单的微服务架构的小demo。 什么是微服务 其实微服务并没有统一的标准定义。微服务是一种软件架构的风格。它首先由大神martin fowler提出，2014年3月25号在他的博客上发表了一篇博客来描述了这种微服务的架构。原文地址（https://www.martinfowler.com/articles/microservices.html）。 相对于传统的单体（Monolithic）架构应用，微服务把单个进程的应用拆分为多个单独部署的服务。每个服务对外提供一些接口来进行服务间的通讯或者对第三方提供功能。每个独立的服务甚至使用自己独立的存储技术，独立的语言技术栈。说到底微服务架构还是贯彻了软件开发中：单一职责、分而治之、解耦等基本理念，只是它把这种理念从类、类库级别提升到了进程级别。 图片引用自https://www.redhat.com/zh/topics/microservices/what-are-microservices [Read More]

Azure Container Registry（容器注册表）是基于 Docker Registry 2.0规范的托管专用 Docker 注册表服务。 可以创建和维护 Azure 容器注册表来存储与管理专用的 Docker 容器映像和相关项目。 Azure Container Registry 类似与阿里云的容器镜像服务。提供镜像的私有存储服务器。对于12月试用账户有100G的免费存储额度及10个Webhook的能力。 依托 Azure 的全球节点可以使你的镜像在全球范围能被访问到并快速拉取。 以下是 Azure Container Registry 的简单试用。 创建资源 在免费服务列表找到容器注册表，点击“创建”。 在弹出的创建界面填写资源组、注册表名称等信息。 位置选择离你近的，比如东南亚。 SKU选择基本。 点击“查看+创建”按钮。 在校验通过后，点击“创建”按钮。 在经过几秒钟的等待后我们的资源就被创建好了，点击“转到资源”可以查看Azure Container Registry的概要信息。 其中比较重要的是右上角的，登录服务器：minjiezhou.azure.io 。后面的操作需要使用到。 上传本地镜像 下面演示下如何通过 Azure CLI 命令行来上传镜像到注册表。 az acr login --name minjiezhou [Read More]

最近维护的一个系统并发有点高，所以想引入一个消息队列来进行削峰。考察了一些产品，最终决定使用kafka来当做消息队列。以下是关于kafka的一些知识的整理笔记。 kafka kafka 是分布式流式平台。它由linkedin开发，后贡献给了Apache开源组织并成为顶级开源项目。它可以应用在高并发场景下的日志系统，也可以当作消息队列来使用，也可以当作消息服务对系统进行解耦。 流处理平台有以下三种特性: 可以让你发布和订阅流式的记录。这一方面与消息队列或者企业消息系统类似。 可以储存流式的记录，并且有较好的容错性。 可以在流式记录产生时就进行处理。 [Read More]