MINJIEZHOU's Blog

上一次我们介绍并演示了如果使用 Consul 做为我们微服务的注册中心，来实现服务的注册与发现。那么本次我们讲会演示如何做日志聚合。日志聚合比较常用的有 ELK 等，但是这次我想要介绍的是一款比较小众的日志聚合工具 - Seq 。 日志聚合 日志是我们写程序离不开的一个东西。在我们排查问题的时候日志就是我们的救命稻草。我们的每个服务都在不停的生产日志。但是实施微服务后，如果按照传统的写本地文件的日志方案，显然会面临跟修改配置一样麻烦的境地。不同的日志分散在各个服务器、容器内，这种情况下查日志简直是生不如死。 日志聚合组件为我们解决了这个问题。所有的服务通过接口发送日志到聚合服务，再由聚合服务进行统一存储，并且提供统一的查询、分析的能力。 日志聚合组件业界有 ELK、Exceptionless、Seq 等。 Seq Seq 是一款使用现代化技术构建的结构化日志存储，查询，分析工具。比起 ELK 这种组合要轻量级许多。只需要一个安装包就具有数据存储，查询，图表分析功能。它对 windows 友好，直接提供了安装包。当然也可以使用 docker 来部署。Seq 对于单个用户是免费的，这对于一些小团队并没有什么问题。Seq 一个比较强大的功能是提供了类似 Sql 语句的数据查询及处理能力，使得用户可以直接写 Select from 来得到自己想要的数据。 seq 的 dashboard 页面。 seq 的查询界面。 seq 网址 使用 docker 安装 docker run --name seq -e ACCEPT_EULA=Y -p 8900:80 -p... [Read More]

上一次我们介绍了 Ocelot 网关的基本用法。这次我们开始介绍服务注册发现组件 Consul 的简单使用方法。 服务注册发现 首先先让我们回顾下服务注册发现的概念。 在实施微服务之后，我们的调用都变成了服务间的调用。服务间调用需要知道IP、端口等信息。再没有微服务之前，我们的调用信息一般都是写死在调用方的配置文件里（当然这话不绝对，有些公司会把这些信息写到数据库等公共的地方，以方便维护）。又由于业务的复杂，每个服务可能依赖N个其他服务，如果某个服务的IP，端口等信息发生变更，那么所有依赖该服务的服务的配置文件都要去修改，这样显然太麻烦了。有些服务为了负载是有个多个实例的，而且可能是随时会调整实例的数量。如果每次调整实例数量都要去修改其他服务的配置并重启那太麻烦了。 为了解决这个问题，业界就有了服务注册发现组件。 假设我们有服务A需要调用服务B，并且有服务注册发现组件R。整个大致流程将变成大噶3部： 服务B启动向服务R注册自己的信息 服务A从服务R拉取服务B的信息 服务A调用服务B [Read More]

AgileConfig 当初是设计给我自己用的一个工具，所以只设置了一道管理员密码，没有用户的概念。但是很多同学在使用过后都提出了需要多用户支持的建议。整个团队或者整个公司都使用同一个密码来管理非常的不方便。 今天 AgileConfig 1.3.0 版本终于支持了多用户，以及简单的权限管理。用户跟权限的设计，在我们开发管理系统的时候经常涉及，最常用的就是RBAC基于角色的权限控制。但是基于 AgileConfig 简单的理念，我稍微简化了一点权限控制的功能设计，尽量的降低学习成本。 权限设计 AgileConfig 的权限设计分为3个固定的角色： 超级管理员 超级管理员具有一切的控制权限，可以随意添加修改删除用户、应用、配置等等任何信息 管理员 普通管理员可以新建应用，可以删除修改属于他的应用（应用的管理员属性为当前用户），以及该应用的配置项。管理员可以给任何用户授权所属应用配置项的管理权限。管理员可以添加修改删除角色为操作员的用户。 操作员 操作员对应用没有任何控制权限，只能编辑或者发布下线经过管理员授权的应用的配置项。 [Read More]

上一次我们通过一张架构图（.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]