之前我们简单介绍过 Go-zero 详见<Go-zero:开箱即用的微服务框架>.这次我们从动手实现一个 Blog 项目的用户模块出发,详细讲述 Go-zero 的使用. 特别说明本文涉及的所有资料都已上传 Github 仓库 "kougazhang/go-zero-demo", 感兴趣的同学可以自行下载. Go-zero 实战项目:blog 本文以 blog 的网站后台为例,着重介绍一下如何使用 Go-zero 开发 blog 的用户模块. 用户模块是后台管理系统常见的模

前两篇文章分别介绍了本系列文章的背景以及根据业务职能对商城系统做了服务的拆分,其中每个服务又可分为如下三类: api服务 - BFF层,对外提供HTTP接口 rpc服务 - 内部依赖的微服务,实现单一的业务功能 rmq服务 - 负责流式任务的处理,如消费kafka等等 admin服务 - 对内部管理后台提供HTTP接口,通常数据操作权限比较高 如果没看过前两篇文章可通过如下传送门查看 go-zero 微服务实战系列(一.开篇) go-zero微服务实战系列(二.服务拆分) 前两篇文章比较偏理论,

本篇是整个系列的最后一篇了,本来打算在系列的最后一两篇写一下关于k8s部署相关的内容,在构思的过程中觉得自己对k8s知识的掌握还很不足,在自己没有理解掌握的前提下我觉得也很难写出自己满意的文章,大家看了可能也会觉得内容没有干货.我最近也在学习k8s的一些最佳实践以及阅读k8s的源码,等待时机成熟的时候可能会考虑单独写一个k8s实战系列文章. 内容回顾 下面列出了整个系列的每篇文章,这个系列文章的主要特点是贴近真实的开发场景,并针对高并发请求以及常见问题进行优化,文章的内容也是循序渐进的,先是介绍

这是Nginx官网写的一个系列,共七篇文章,如下 Introduction to Microservices (this article) Building Microservices: Using an API Gateway Building Microservices: Inter-Process Communication in a Microservices Architecture Service Discovery in a Microservices Architecture E

希望给你3-5分钟的碎片化学习,可能是坐地铁.等公交,积少成多,水滴石穿,码字辛苦,如果你吃了蛋觉得味道不错,希望点个赞,谢谢关注. 前言 这里记录的是个人奋斗和成长的地方,该篇只是一个系列目录和构想,并没有完全真正开弓.之所以有这个题目,是因为.NET Core在国内的学习资源七零八落,偶尔园里也有零星好文出现,但是系统性的,带深入浅出实战风格的专题介绍目前没有看到,之前特定整理了一个资源分享,持续收集了不少资源,但是总感觉还是做的不够好,对个体或团队要进行技术升级还是没有门道可循. 目前关于

微服务实战(一):微服务架构的优势与不足 微服务实战(二):使用API Gateway 微服务实战(三):深入微服务架构的进程间通信 微服务实战(四):服务发现的可行方案以及实践案例 微服务实践(五):微服务的事件驱动数据管理 微服务实践(六):选择微服务部署策略 微服务实践(七):从单体式架构迁移到微服务架构

简介 小程序可以通过微信官方提供的登录能力方便地获取微信提供的用户身份标识,快速建立小程序内的用户体系. 系列 云原生 API 网关,gRPC-Gateway V2 初探 业务流程 官方开发接入文档 初始化项目 开发环境 为少 的本地开发环境 go version # go version go1.14.14 darwin/amd64 protoc --version # libprotoc 3.15.7 protoc-gen-go --version # protoc-gen-go v1.26

前言 在社区中经常看到有人问有没有基于 go-zero 的比较完整的项目参考,该类问题本质上是想知道基于 go-zero 的项目的最佳实践.完整的项目应该是一个完整的产品功能,包含产品需求.架构设计.关键流程的编码.表设计以及各种性能优化和数据一致性等,是一个真正贴近生产级的项目,是可以直接拿来在自己的生产项目中进行参考的,而目前社区并没有类似的比较完整的开源项目参考,因此决定和大家一起从零开始基于 go-zero 构建一个完整的贴近生产的项目. 该系列的主题是基于 go-zero 构建一个高并

1. 场景描述 前几天介绍了下springcloud的Eureka注册中心(springcloud-注册中心快速构建),今天结合springboot-web介绍下eureka客户端服务注册. 2. 解决问题 2.1 新建eureka客户端项目 2.1.1 new->project 2.1.2 项目名称改一下 2.1.3 依赖包选择 (1)选择web的starter,等下跑测试使用. (2)注册中心客户端依赖包选择 next->finish 2.2 项目介绍 三个类,就可以跑起来了. 2.2.1

1.场景描述 因要用到微服务,关于注册中心这块,与同事在技术原型上做了讨论,初步定的方案是使用:阿里巴巴的nacos+springcloud gateway,下面表格是同事整理的注册中心对比,以前用的springcloud的eureka作为注册中心,与eurka相比,这次之所以用阿里的nacos,其中还有一个主要的原因就是nacos集成了动态加载,不用重启网关,动态加载服务配置等. 注册中心对比: Feature Zookeeper Eureka Consul Etcd Nacos 服务健康检查

1. 场景描述 nacos最近用的比较多,介绍下nacos及部署吧,刚看了下以前写过类似的,不过没写如何部署及与eureka区别,只展示了效果,补补吧. 2.解决方案 2.1 nacos与eureka简要描述 (1)springcloud eureka是注册中心,负责微服务的注册与发现,起到承上启下的作用,在微服务架构中相当于人体的 大脑,很重要,nacos是阿里巴巴出的,功能类似eureka,区别不再啰嗦了. (2)nacos的部署方式与springcloud eureka不太一样,eurak

1. 场景描述 今天接着介绍springcloud,今天介绍下springcloud的路由网关-Zuul,外围系统或者用户通过网关访问服务,网关通过注册中心找到对应提供服务的客户端,网关也需要到注册中心进行注册. 2. 解决方案 2.1 官网架构图 先把官网的图在贴一下,便于理解. 说明: gateway负责与外部进行交互,是sprincloud微服务对外的窗口. 2.2 开始撸码 2.2.1 new->project 2.2.2 选择组件 (1)注册客户端 (2)路由Zuul next->n

1. 场景描述 springcloud刚推出的时候用的是netflix全家桶,路由用的zuul,但是据说zull1.0在大数据量访问的时候存在较大性能问题,2.0就没集成到springcloud中了,springcloud推出了自己的路由-springcloud gateway,亲儿子,目前官网主推. netfelix的zull路由: <dependency> <groupId>org.springframework.cloud</groupId> <artifa

1. 场景描述 先说明下项目中使用的网关是:springcloud gateway, 因需要给各个网关服务系统提供自定义配置路由规则,实时生效,不用重启网关(重启风险大),目前已实现:动态加载自定义路由文件,动态加载路由文件中的路由规则. 2.解决方案 2.1 解决思路 新建总的监控总类,监控网关服务路由规则配置文件,然后每个路由配置文件再监控内容自己文件内容是否变化,动态加载到springcloud gateway中. 2.2 配置规则说明 bc-ruanjianlaowang-all.yam

1.场景描述 因为要做网关的高可用,用到了keepalived+nginx,来保证nginx的高可用,如下图: 安装了keepavlived,走了一些弯路,记录下吧,nginx的安装就不多说了,博客已经介绍了好几篇了. 2. 解决方案 2.1 安装keepalived 2.1.1 安装相关依赖包 [root@t-ruanjianlaowang ~]# yum install -y libnl* [root@t-ruanjianlaowang ~]# yum install -y libnfnet

微服务概述 微服务架构是一种架构风格,它将一个大的系统构建为多个微服务的集合,这些微服务是围绕业务功能构建的,服务关注单一的业务功能,这些服务具有以下特点: 高度可维护和可测试 松散的耦合 可独立部署 围绕业务功能进行构建 由不同的小团队进行维护 微服务架构能够快速.频繁.可靠地交付大型.复杂的应用程序,通过业务拆分实现服务组件化,使用组件进行组合从而快速开发系统. 服务划分 我们首先进行微服务的划分,在实际的项目开发中,我们通常采用两种微服务划分策略,第一种方式是通过业务职能进行微服务边界的划

上一篇文章我们把整个项目的架子搭建完成,服务在本地也已经能运行起来了,顺利成章的接下来我们就应该开始写业务逻辑代码了,但是单纯的写业务逻辑代码是比较枯燥的,业务逻辑的代码我会不断地补充到 lerbon 项目中去,关键部分我也会加上注释. 那么本篇文章我主要想和大家分享下服务的基本配置和几个典型的代码示例. 日志定义 go-zero的 logx 包提供了日志功能,默认不需要做任何配置就可以在stdout中输出日志.当我们请求/v1/order/list接口的时候输出日志如下,默认是json格式输出

缓存是高并发服务的基础,毫不夸张的说没有缓存高并发服务就无从谈起.本项目缓存使用Redis,Redis是目前主流的缓存数据库,支持丰富的数据类型,其中集合类型的底层主要依赖:整数数组.双向链表.哈希表.压缩列表和跳表五种数据结构.由于底层依赖的数据结构的高效性以及基于多路复用的高性能I/O模型,所以Redis也提供了非常强悍的性能.下图展示了Redis数据类型对应的底层数据结构. 基本使用 在go-zero中默认集成了缓存model数据的功能,我们在使用goctl自动生成model代码的时候加上

前两篇文章我们介绍了缓存使用的各种最佳实践,首先介绍了缓存使用的基本姿势,分别是如何利用go-zero自动生成的缓存和逻辑代码中缓存代码如何写,接着讲解了在面对缓存的穿透.击穿.雪崩等常见问题时的解决方案,最后还重点讲解了如何保证缓存的一致性.因为缓存对于高并发服务来说实在是太重要了,所以这篇文章我们还会继续一起学习下缓存相关的知识. 本地缓存 当我们遇到极端热点数据查询的时候,这个时候就要考虑本地缓存了.热点本地缓存主要部署在应用服务器的代码中,用于阻挡热点查询对于Redis等分布式缓存或者数

在前几篇的文章中,我们花了很大的篇幅介绍如何利用缓存优化系统的读性能,究其原因在于我们的产品大多是一个读多写少的场景,尤其是在产品的初期,可能多数的用户只是过来查看商品,真正下单的用户非常少.但随着业务的发展,我们就会遇到一些高并发写请求的场景,秒杀抢购就是最典型的高并发写场景.在秒杀抢购开始后用户就会疯狂的刷新页面让自己尽早的看到商品,所以秒杀场景同时也是高并发读场景.那么应对高并发读写场景我们怎么进行优化呢? 处理热点数据 秒杀的数据通常都是热点数据,处理热点数据一般有几种思路:一是优化,二

上一篇文章中引入了消息队列对秒杀流量做削峰的处理,我们使用的是Kafka,看起来似乎工作的不错,但其实还是有很多隐患存在,如果这些隐患不优化处理掉,那么秒杀抢购活动开始后可能会出现消息堆积.消费延迟.数据不一致.甚至服务崩溃等问题,那么后果可想而知.本篇文章我们就一起来把这些隐患解决掉. 批量数据聚合 在SeckillOrder这个方法中,每来一次秒杀抢购请求都往往Kafka中发送一条消息.假如这个时候有一千万的用户同时来抢购,就算我们做了各种限流策略,一瞬间还是可能会有上百万的消息会发到Kaf