Question

我们的微服务堆栈现在已经为业务逻辑提供了多达15项小型服务，如Auth，消息传递，计费等。现在，docker-compose up使用的ram超过了我们的开发人员所拥有的数量。在他们的笔记本电脑上

这不是一个疯狂的数量，大约4GB，但我经常感受到我的8GB机器上的压力（谢谢，Chrome）。

我们可以做到并确实正在进行应用程序级别的优化，但最终我们还需要一种替代策略。

我看到两个明显的选择：

使用大型多云开发机器，可能配备了泊坞机和aws。
将一些机器分解为共享开发云，如postgres和redis

这些并不令人满意，在（1）中，本地文件没有同步，使本地开发成为噩梦，在（2）中我们可以打破彼此的环境。

帮助！

Apendix I：来自docker stats的输出

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O               BLOCK I/O
0ea1779dbb66        32.53%              137.9 MB / 8.186 GB   1.68%               46 kB / 29.4 kB       42 MB / 0 B
12e93d81027c        0.70%               376.1 MB / 8.186 GB   4.59%               297.7 kB / 243 kB     0 B / 1.921 MB
25f7be321716        34.40%              131.1 MB / 8.186 GB   1.60%               38.42 kB / 23.91 kB   39.64 MB / 0 B
26220cab1ded        0.00%               7.274 MB / 8.186 GB   0.09%               19.82 kB / 648 B      6.645 MB / 0 B
2db7ba96dc16        1.22%               51.29 MB / 8.186 GB   0.63%               10.41 kB / 578 B      28.79 MB / 0 B
3296e274be54        0.00%               4.854 MB / 8.186 GB   0.06%               20.07 kB / 1.862 kB   4.069 MB / 0 B
35911ee375fa        0.27%               12.87 MB / 8.186 GB   0.16%               29.16 kB / 6.861 kB   7.137 MB / 0 B
49eccc517040        37.31%              65.76 MB / 8.186 GB   0.80%               31.53 kB / 18.49 kB   36.27 MB / 0 B
6f23f114c44e        31.08%              86.5 MB / 8.186 GB    1.06%               37.25 kB / 29.28 kB   34.66 MB / 0 B
7a0731639e31        30.64%              66.21 MB / 8.186 GB   0.81%               31.1 kB / 19.39 kB    35.6 MB / 0 B
7ec2d73d3d97        0.00%               10.63 MB / 8.186 GB   0.13%               8.685 kB / 834 B      10.4 MB / 12.29 kB
855fd2c80bea        1.10%               46.88 MB / 8.186 GB   0.57%               23.39 kB / 2.423 kB   29.64 MB / 0 B
9993de237b9c        40.37%              170 MB / 8.186 GB     2.08%               19.75 kB / 1.461 kB   52.71 MB / 12.29 kB
a162fbf77c29        24.84%              128.6 MB / 8.186 GB   1.57%               59.82 kB / 54.46 kB   37.81 MB / 0 B
a7bf8b64d516        43.91%              106.1 MB / 8.186 GB   1.30%               46.33 kB / 31.36 kB   35 MB / 0 B
aae18e01b8bb        0.99%               44.16 MB / 8.186 GB   0.54%               7.066 kB / 578 B      28.12 MB / 0 B
bff9c9ee646d        35.43%              71.65 MB / 8.186 GB   0.88%               63.3 kB / 68.06 kB    45.53 MB / 0 B
ca86faedbd59        38.09%              104.9 MB / 8.186 GB   1.28%               31.84 kB / 18.71 kB   36.66 MB / 0 B
d666a1f3be5c        0.00%               9.286 MB / 8.186 GB   0.11%               19.51 kB / 648 B      6.621 MB / 0 B
ef2fa1bc6452        0.00%               7.254 MB / 8.186 GB   0.09%               19.88 kB / 648 B      6.645 MB / 0 B
f20529b47684        0.88%               41.66 MB / 8.186 GB   0.51%               12.45 kB / 648 B      23.96 MB / 0 B

Answer 1

我们一直在努力解决这个问题，但仍然没有一个理想的解决方案。但是，我们目前正在讨论两个想法。

运行＆＃34; Dev＆＃34;云中的环境，不断更新每个图像的主/最新版本。然后，每个单独的项目都可以在其docker-compose.yml文件中代理该环境......因此它们在本地运行THEIR服务，但所有依赖项都是远程的。这个（从你的问题）的一个重要部分是你有共享的依赖，如数据库。绝不应该这样......永远不要整合数据库。每项服务都应存储自己的数据。
每项服务都负责建立一个＆＃34; mock＆＃34;他们的应用程序版本，可用于本地开发和中级集成测试。模拟版本不应该具有依赖性，并且应该允许某人仅需要来自其服务的单个层（3或4个模拟，而不是3或4个真实服务，每个服务具有自己的3或4个等等））。

没有足够的ram来运行整个docker-compose堆栈

1 个答案: