暂无个人介绍
本系列的第二讲,我原先计划聊一下OpenTracing这个技术,但计划赶不上变化,我发现OpenTracing的官网上已经声明:这部分的技术将迁移到OpenTelemetry。
十二要素应用原则(The Twelve-Factor App) 在如今的微服务领域非常流行,相信大家或多或少有所耳闻,但了解其中细节的并不多。 今天,我将对这12个原则做一个概要分析,结合Go语言中的相关例子,根据开源与大厂的具体实践,和大家一起看看个中究竟。
理解 kubelet 的运行机制
理解 kube-controller-manager 的运行机制
理解一个pod的被调度的大致流程
了解Informer在发现资源变化后,是怎么处理的
了解Informer是如何从kube-apiserver监听资源变化的情况
理解kube-scheduler启动的流程
理解Pod发送到kube-apiserver后是怎么保存的
理解kube-apiserver是中的管理核心资源的KubeAPIServer是怎么启动的
理解kubectl是怎么向kube-apiserver发送请求的
理解kubectl的核心实现之一:Visitor Design Pattern 访问者模式
我们的目标是查看`kubectl create -f nginx_pod.yaml` 这个命令是怎么运行的。
部署Kubernetes集群的方法(建议用kubeadm),详细可参考我的博客,或者可直接参考[官方文档]
首先,针对读源码是先看源代码还是测试代码,因人而异。个人建议在对源码毫无头绪时,先从测试入手,了解大致功能;如果有一定基础,那么也可以直接入手源代码。我认为优秀的Go源码可读性是非常高的,所以一般情况下,我都直接从源文件入手,遇到问题才会去对应的测试里阅读。
从这里可以看出,gRPC虽然是支持多语言,但原生的实现并不多。如果想在一些小众语言里引入gRPC,还是有很大风险的,有兴趣的可以搜索下TiDB在探索rust的gRPC的经验分享。
在第一部分,我们学习了gRPC的基本调用过程,这样我们对全局层面有了一定了解。接下来,我们将结合官方文档,继续深入学习、探索下去。
- 分析PB生成的对应文件 - 运行server - 运行client
良好的命名能体现出其价值。尤其是在错误码的处理上,无需再去查询错误码对应的错误内容,直接可以通过命名了解。
但是,我不建议大家在实际项目中直接使用这一块代码,毕竟其中大量的反射操作是比较耗时的,尤其是在延迟非常敏感的web服务器中。 如果我们多花点时间、直接编写指定类型的代码,那么就能在编译期发现错误,运行时也可以跳过反射的耗时。
今天我们专注于自定义服务中的Prometheus的监控,在框架中引入Prometheus相关的组件。关于更细致的使用方式,我会给出相关的链接,有兴趣进一步学习Prometheus的同学可以边参考资料边实践。
随着接口参数校验功能的完善,我们能快速定位到接口层面的参数问题;而应用服务的分层代码,也可以通过log的trace-id发现常见的业务逻辑问题。 但在最底层与数据库的操作,也就是对GORM的使用,经常会因为我们不了解ORM的一些细节,导致对数据的CRUD失败,或者没有达到预期效果。这时,我们希望能在ORM这一层也有一个通用的解决方案,来加速问题的排查。
大量开发接口的朋友会经常遇到**接口参数校验**的问题。举个例子,我们希望将某个字段是必填的,如`name`,我们经常会需要做两步: 1. 在程序中加一个**判断逻辑**,当这个字段为空时返回错误给调用方 2. 在接口文档中加上**注释**,告诉调用方这个参数必填 一旦某项工作被拆分为两步,就很容易出现**不一致性**:对应到参数检查,我们会经常遇到文档和具体实现不一致,从而导致双方研发的沟通成本增加。那么,今天我将引入一个方案,实现两者的一致性。
随着项目的迭代,一个服务会开放出越来越多的接口供第三方调用。 虽然`protobuf`已经是通用性很广的IDL文件了,但对于未接触过这块的程序员来说,还是有很大的学习成本。在综合可读性和维护性之后,我个人比较倾向于使用oepnapiv2的方案,提供在线接口文档。
我们从API层到数据库层的链路已经打通,简单的CRUD功能已经可以快速实现。 随着模块的增加,我们会越发感受到系统的复杂性,开始关注系统的可维护性。这时,有个名词会进入我们的视野:**分布式链路追踪**
我们对比一下GORM库提供的`gorm.Model`,它在新增、修改时,会自动修改对应的时间,这个可以帮我们减少很多重复性的代码编写。这里,我就针对现有的gormer工具做一个示例性的迭代。
作为一名程序员,我们总是希望能有更简单的开发方式来解决重复性的工作问题。在这个小版本中,我将结合自己的工作,来给出一套自动生成代码的完整方案,供大家借鉴。
随着RPC与MySQL的打通,整个框架已经开始打通了数据的出入口。 接下来,我们就尝试着实现通过RPC请求操作MySQL数据库,打通整个链路,真正地让这个平台实现可用。
与此同时,我们也缺乏一个有效的手段来验证自己编写的相关代码。如果依靠连接到真实的MySQL去验证功能,那成本实在太高。那么,这里我们就引入一个经典的sqlmock框架,并配合对数据库相关代码的修改,来实现相关代码的可测试性。
GORM库是一个很强大、但同时也是一个非常复杂的工具。为了支持复杂的SQL语言,它比之前的配置文件加载工具github.com/spf13/viper要复杂不少。今天,我们不会全量地引入GORM里的所有特性,而是从一个最简单的场景入手,对它的基本特性有所了解。而后续随着框架的完善,我们会逐渐细化功能。
衡量日志库有多个指标,我们今天重点关注两点:简单易用 与 高性能。简单易用是一个日志库能被广泛使用的必要条件,而高性能则是企业级的日志库非常重要的衡量点,也能在源码层面对我们有一定的启发。
今天,我们先将重点放到加载配置文件库的技术选型,顺便分享一些常见的问题。
大家好,我是六月天天。如题所述,从今天开始,我将和大家一起逐步完成一个微服务框架。
在上一讲,我们梳理了`EtcdServer`的关键函数`processInternalRaftRequestOnce`里的四个细节。 其中,`wait.Wait`组件使用里,我们还遗留了一个细节实现,也就是请求的处理结果是怎么通过channel返回的。
在上一讲,我们继续梳理了`PUT`请求到`EtcdServer`这一层的逻辑,并大概阅读了其中的关键函数`processInternalRaftRequestOnce`。
在上一讲,我们一起看了etcd server是怎么匹配到对应的处理函数的,如果忘记了请回顾一下。 今天,我们再进一步,看看`PUT`操作接下来是怎么执行的。
在阅读了etcd server的启动流程后,我们对很多关键性函数的入口都有了初步印象。 那么,接下来我们一起看看对键值对的修改,在etcd server内部是怎么流转的。
在第一阶段,我将从主流程出发,讲述一个`PUT`指令是怎么将数据更新到`etcd server`中的。今天,我们先来看看server是怎么启动的。
如果要更深入地研究etcd,就需要我们涉及到源码、并结合实践进行学习。那么,接下来,我将基于`v3.4`这个版本,做一期深入的环境搭建。
有人常说,编程语言对软件工程师来说并不重要,更重要的是软件工程思想、架构设计能力等更高层面的内容。 这个观点本身没有问题,但它更多的是针对有相当工作经验的程序员。对于绝大多数的人,编程语言依然是最重要、最核心的技能,也是通往更高层面的敲门砖。所以,精通一门编程语言,不仅仅要熟悉其语法与原理,更要了解其周边的生态,包括框架、开源库、中间件等,以及掌握它适用的业务场景。
通过前面几讲的分享,相信大家已经能清楚地看到一名普通软件工程师的发展路线:不断学习技能,提高研发效能,实现业务功能。 如果我们尝试回头看,可能会对自己的定位存在疑问:这些日常CRUD的开发工作,很多不具备太高的技术难度,可以靠人力堆积来实现。那么,如何在研发团队里打造自己的技术壁垒、体现个人价值呢?
在入门篇与基础篇之后,我选择做了这一讲提效篇。而在提效篇的推出之前,我也开启[Go语言技巧系列](https://junedayday.github.io/tags/Go-Tip/)的更新,着重分享一些具体的工程化实例,包括错误处理、Go Module等。
经过了 入门篇 的学习,大家已经初步了解Go语言的语法,也能写常见的代码了。接下来,我们就从一个Web项目入手,看看一些常见的技能与知识吧。 我们先简单地聊一下这个Web项目的背景:我们要做的是一个简单的web系统 ,有前端同学负责界面的开发,后端不会考虑高并发等复杂情况。
如今互联网资料泛滥,入门编程语言的途径有很多种选择,但如果要我推荐,只有一个建议 - 研读一本该编程语言最优秀的基础书籍。 对于Go语言,我推荐 《Go程序设计语言》(The Go Programming Language),也被称为 Go语言圣经。
终身成长 一词已被广泛认可,意味着我们将比前人花费更多的时间在学习成长中,才能将个人的认知跟上社会的步伐。且不论是否应该放慢脚步,但我们大部分人不得不跟随社会的节奏,持续学习并提高自己。
如何成为一名优秀的Go语言工程师,这是很多人都长期疑惑的问题。 我这边抛出自己的观点,希望能引起大家的思考: 掌握基础,熟悉生态,集百家长,深耕领域 接下来,我将围绕这四个词展开今天的分享。
目前,后端开发语言的就业方向主要分为两块:业务系统开发 与 基础平台开发 。Go语言自然也不会例外。
通过上一讲,我们对gRPC的拦截器有了一定的认识,也能定制出很多通用的中间件。 但在大部分的业务系统中,我们面向的还是HTTP协议。那么,今天我们就从gRPC-Gateway的mux选项出发,一起来看看一些很实用的特性。
我们在前几讲提到过,优秀的RPC框架都提供了`middleware`的能力,可以减少很多重复代码的编写。在gRPC-Gateway的方案里,包括了两块中间件的能力: 1. gRPC中的`ServerOption`,是所有gRPC+HTTP都会被处理 2. gRPC-Gateway中的`ServeMuxOption`,只有HTTP协议会被处理 今天,我们先关注共同部分的`ServerOption`,它提供的能力最为全面,让我们一起了解下。
今天,我们先迈出第一步:探索RPC服务中的数据类型。掌握常见的数据类型,灵活地运用到接口设计中,能帮助我们快速地提供优雅的接口类服务。