前言

有些时候，我们会发现，[]byte 类型在 struct 中，是必不可少的结构体，因为用了[]byte代表可以存储字节数据，也可以叫做二进制安全的存储。代表可以存储任何数据。

如何才能做到在序列化json的情况下，可以Println出一个可读性的在struct的[]byte呢？

前言

上一次，我们说到了docker-for-mac 已经内置了最小化的k8s。我们在本地开发的时候，或多或少希望yaml配置是最接近线上环境的配置。

因此，上一次，教会了大家，如何在mac上开启nfs,把我们的pv和本地mac的nfs进行一个通信。

这一次，我们来聊聊docker-for-mac磁盘挂在的相关内容。

前言

我们经常有一些日志采集的需求，采集完毕之后，希望有一个中心WebUi来方便的查看很多不同节点，不同服务的日志。

按照传统的方式，一般都是会采用ELK,就是elasticsearch+logstash+kibana，但是由于JVM对资源的消耗太大，加上ES是通过全文搜索的方式需要进行倒排索引的分词，所以这些功能几乎是用不上，我们查询日志一般都可以通过定制常规的label信息，然后搜索即可，大可不必进行分词的行为。尽管后续又由于logstash的资源占用过大问题，作者又利用go语言开发出了filebeat，来辅助日志采集体系，后续加入了某公司之后，被集成到了beats的项目中，因为也可以交efk/ebk，都可以。

鉴于这一点，随之而来的就是GLP，就是grafna+loki+promtail。这是一套完全基于go语言生态写的，更贴近云原生。一套体系都是经过grafna lab云原生孕育而生。资源占用少，效率高，能够解决痛点，天生支持k8s等等特性。都让他成为新的崛起之秀。

前言

docker-for-mac 现在已经内置了k8s，我们可以轻松的开启这个功能，然后就可以通过kubectl来执行我们的k8s的命令来对容器资源进行管理。

但是有一个比较头疼的点，那就是我们的pv资源。我们平时用docker的时候，有一些信息例如，日志之类的，需要持久化下来，这个时候，这个日志文件持久化会和容器所在的物理机在同一个机器下，因此，并不能很好的做到“存”，“算”分离的目的。并且没办法利用了网络上的其他资源。

再者就是还有一种情况就是，我需要利用k8s部署一些基础服务，例如mysql，例如redis，这些基础数据都是需要持久化的，因此，和物理机器强行绑定在一起的话，下次数据在哪个数据卷都不清楚了，更没办法重新回复数据，这是一个很严重的问题。

所以我们这里的pv，不能简单的使用hostPath或者local类型，根据服务器上用的比较多的或许是自己搭建一个nfs 服务器，因此，我们也希望在本地开发的时候定义资源文件的yaml也是用nfs来作为我们的pv-type。

但是也因此，我们需要在mac上开启一个nfs-server。尝试过docker-nfs-server，但是由于mac系统的架构问题，无法顺利的运行起来，需要处理modpre模块，处理那么多内核的东西不太合理。

前言

最近，在处理公司到代码仓库，公司由gitbucket迁移到gitlab后，业务项目拉取私有vcs的代码依赖包的方式发生了改变。

以前可能是一个“权限较大”的用户，拥有多个项目组的访问权限，所以可以访问私有的vcs的代码。

但是迁移到gitlab之后，每个group下，owner都可以针对这个group生成对应都deploy-key，所以变成了一个group下一个deploy-key。

这就意味着，我们都go/php/node项目，在拉取不同项目都依赖包都时候，需要把git-credential的账号信息切换。

前言

Rust 中有一个 99%的程序员或许都会用到的组件，那就是序列化组件: serde。

众所周知，rust的静态语言，所以这让我们在序列化上繁琐了很多，但是有了serde，它帮助我们更好的序列化结构体，生产对应的数据。它实现了各种声明宏 以及 过程宏 来协助我们序列化。

围绕着serde，也有很多衍生的子组件，例如serde-json, serde-yaml, serde-qs 等等。

由于我目前在开发 gitlab-rs，在生成对应的query_string 以及form的数据的时候，就比较棘手。

所以我在gitlab-rs 生成的过程宏中，借助了 seder 出色的序列化生态来完成功能。

前言

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

msource 是我们的一个 数据源组件，我们所有的大数据ETL服务都构建在此之上，所以我们msource可以说是所有业务系统的核心。他维护着一个稳定，可靠，高性能的数据传输机制。让我们 业务层 中可以做各种操作，同步，异步等等。

msource 的角色我大体分为了2种：

• spout （数据推送组件)
• db （数据存储组件）

前言

由于目前在使用使用一些go写的odbc库，里面涉及到一些cgo的内容，那就避不开内存和指针等问题，在这边文章中记录一下unsafe Pointer 和 uintptr 的相关内容。

Go语言在设计的时候，为了编写方便、效率高以及降低复杂度，被设计成为一门强类型的静态语言。强类型意味着一旦定义了，它的类型就不能改变了；静态意味着类型检查在运行前就做了。

同时为了安全的考虑，Go语言是不允许两个指针类型进行转换的。

前言

由于我们要尝试使用kudu，架构是由flume->kudu

前言

由于我们在调研是否让自建IDC大数据机房上云服务，所以华为云进行一下测试。