MINJIEZHOU's Blog

上一次我们介绍了Elastic APM组件。这一次我们继续介绍微服务相关组件配置中心的使用方法。本来打算介绍下携程开源的重型配置中心框架 apollo 但是体系实在是太过于庞大，还是让我爱不起来。因为前面我们已经介绍了使用Consul 做为服务注册发现的组件，那么干脆继续使用 Consul 来作为配置中心吧。Consul 除了服务注册发现功能，还有个 Key/Value 存储的功能，我们把本地的 appsettings.json 文件的内容搬到 Key/Value 上就可以实现配置中心了。 把服务的配置迁移至 Consul 让我们来改造一下前面系列文章里的 member_center 项目，把配置文件都迁移到 consul 上面去。 在 consul 控制台点击 “Key/Value” 菜单，点击 “create” 按钮新建一个 Key/Value 对象。 Key/Value 支持按文件夹分类，当我们的 Key 以 / 结尾的时候，consul 会认为这是一个文件夹。 我们在这里输入 “member_center/” 在创建文件夹。 在创建的文件夹目录下继续点击 “create” 按钮。 在 key 文本框里输入 “confing.json” 。 在 Value... [Read More]

上一次我们介绍了Seq日志聚合组件。这次要给大家介绍的是Elastic APM ，一款应用程序性能监控组件。APM 监控围绕对应用、服务、容器的健康监控，对接口的调用链、性能进行监控。在我们实施微服务后，由于复杂的业务逻辑，服务之间的调用会像蜘蛛网一样复杂。有了调用链监控后服务之间的调用可以用图像的方式展示出来，每个请求的性能，响应等都会记录下来。对于提前防范问题，以及排查问题有非常大的意义。 Elastic APM 大家对 ELK 套件一定非常熟悉。ELastic APM 同样也是 Elastic 系列产品的一个组件。Elastic APM 是一款免费开源的应用程序性能监控组件。它底层依赖 Elasticsearch 来存储跟查询数据，使用 Kibana 来展示分析数据。它支持多种程序语音的探针，包括 JAVA，.NET, Nodejs 等语音。对于 .NET 的集成非常方便，只要简单的配置就可以采集 .NET 程序的信息，对代码几乎是零入侵。 Elastic APM 的架构由4个部分组成。 Elasticsearch 负责数据的持久化，查询等能力 Kibana APM数据的分析展示界面 APM Agent 每个服务集成对应的 sdk 后就是一个个 agent，负责采集程序的各种指标数据 APM Server ，agent 采集到数据后会上报给 APM Server ，由APM Server汇集数据后存储到 Elasticsearch 。 [Read More]

上一次我们介绍并演示了如果使用 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]