最近windows升级到2004后，尝试全面转WSL2来操作命令行，但是今天我在写一个小玩意的时候，刚在idea中将所有文件提交了commit，准备使用WSL2来操作git整理一下历史commit，发现结果和想象的不太一样。

本文使用wsl2上的docker进行部署，项目地址为：https://github.com/JetBrains/projector-docker。

我的搬瓦工19刀的小鸡内存太小了，我在上面搭载了很多服务，比如这个博客、oneindex、网关等等，512M的内存分分钟就要爆满。因此，需要扩大服务器的内存。但是我们都知道内存是购买服务器的时候就定死的配置，无法更改了。所以这里我们就需要用到Swap分区了。

我一直觉得作为一个自用的微型vps，没必要使用nginx这种复杂的web服务端。我以前一直使用goflyway，它是一个使用Golang编写的自带反代理功能的隧道HTTP隧道代理工具。但是goflyway的反代理功能太弱了。这次我替换了一个更好的工具——Caddy。

我们都知道因为一些不可描述的原因，国内下载GitHub的速度非常慢，虽然有挂代理、利用码云中转后再重新指定remote等方法加速下载，但是终归不是特别方便，因此决定写一个小玩意来部署在网路畅通的小鸡上，提供在线接口提供代理Git的目的。

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

CAP 定理（CAP theorem）是分布式系统（distributed system）领域非常著名的一个定理。 分布式系统正变得越来越重要，大型网站几乎都是分布式的。 分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

在项目的实际开发中，开发人员本地开发时，不希望本地将整个调用链启动，不想启动多个服务，渴望接入测试环境，既能依赖测试环境的上游服务，同时并不希望自己会影响到下游服务。思路为了解决整个问题，我们发现开发环境的本地微服务（例如IP地址为172.16.0.8）已经注册到测试环境的服务注册发现中心，那么可以

Compose和Docker兼容性对应表Compose有多种版本的文件格式:1，2，2.x和3.x。下表是各版本的快速浏览。有关每个版本包括什么内容以及如何升级的完整详细信息，请参阅官方的**关于版本和升级**。下表显示了哪些Compose文件版本支持哪些特定的Docker版本。docker-com

在我们的微服务部署中，一套服务使用同一个compose工程，同属于一个网络，不向宿主机暴露端口，只进行容器间的网络通信，无疑大大增强了安全性。