微服务就是把每个数据交换不是非常频繁，并发有较大区别的服务都做成 API 放进不同容器吗？想把一个 ASP.NET Core 写的网站改造成微服务，这个方案 V 友有什么意见吗？

[rv54ntjwfm3ug8]

一个社区网站，并发不算很多也不算很少，目前数据库和前后端都在一台某大厂 2 核 8g 运存的 VPS 上，日常负载 30%～ 75%，我想把它分成以下几个容器：

1. Backend 提供用于客户端和 Web 容器获取帖子 /发帖等的 API ，和 Admin 容器共用数据库
2. Web 网页版模版渲染，当网页版被请求时由服务器去调 Backend 容器的 API 获取帖子渲染成静态 HTML 后返回，无数据库
3. Cron 处理定时发通知等计划任务，提供用于 Admin 容器编辑计划任务的 API ，独立数据库
4. Admin 提供管理相关 API ，和 Backend 容器共用数据库

最后再来一个 Nginx 反代和分发静态资源 /后台的前端页面（非服务器渲染） 想问问：

1. 有容器建议合并吗？
2. 用户登录有没必要单独再分个 Auth 容器出来？
3. 如果部署在同一台服务器上，容器间通信有没有必要上 HTTPS ？如果部署在不同服务器用云厂商内网呢？

或者有没有更好的方案？如果这不算微服务，应该怎么把它改造成微服务？

[kkjinping]

微服务一般还要有与之匹配的服务治理：服务注册、发现、负载均衡、限流熔断、消息组件、网关、配置中心、调度中心等。

把一些服务分到多个容器，其实只是做了服务的拆分。但一般个人的小站，没必要上微服务的整套体系。

[kkjinping]

微服务的目的还是为了各个服务自治、更好的扩容、提供硬件利用率。但是维护难度很高。

[ktqFDx9m2Bvfq3y4]

楼主研究一下 Dapr ，基本上它都帮你封装好了。

[seakingii]

自己还摸不着头脑的时候先别上吧,别自找麻烦

[ch2]

一台 2 核 8G 就别折腾了吧，微服务是每个服务都有好几台机器运行多个容器以多占用计算资源为代价换来灵活性。你一没有计算资源，二估计也没有人力资源，完全得不偿失

[kowgarnett]

如果你觉得负载是个问题，你上了微服务可能负载依然是问题，因为你的 VPS 的可用资源没变，而且你可能还需要额外的开销去维持多个容器运行时，很有可能得不偿失。。。而且上微服务通常是是为了扩展性，而拥有扩展性的前提就是你有足够的计算资源去给它扩展。。。

[rv54ntjwfm3ug8]

@kowgarnett #6 上微服务就是为了以后规模变大加机器方便
@ch2 #5 那还有什么方便扩展的方案么

[nothingistrue]

有容器建议合并吗？
数据不拆分则服务不拆分，Backend 与 Admin 要合并。

用户登录有没必要单独再分个 Auth 容器出来？
现在不要，将来的事看将来的情况。

如果部署在同一台服务器上，容器间通信有没有必要上 HTTPS ？如果部署在不同服务器用云厂商内网呢？
不管你是部署在同一台，还是不同台，都要把它当成部署在不同的地方看，这样才省事。纯内网没必要上 HTTPS ，当然你要愿意折腾可以一部到位，但这个真不好折腾。

关于你那个 Backend 、Admin 、Auth 的拆分问题。首先要看业务界限，简单来说就是数据库上能不能独立出来，数据不独立就一定没法拆。其次要看你的实际伸缩性要求了，伸缩性要求不高的话，那怕三个都是超高度内聚的，都可以放到一个服务里面。

[forgottencoast]

@theklf4
“2 核 8g 运存的 VPS ” 距离“规模变大加机器”还远得很咧。
第一步你可以把数据库分离出来，然后还可以前后端分离，然后给 VPS 不断的加 CPU 和内存。
上面这些操作可以不断的提高服务的支撑量，但是几乎不用你花费多少精力。
那句话怎么说来着：“提前优化是万恶之源。”
先把有限的精力投入到优化业务上面。