xiaogu2014

```不采用微服务架构```
```选一个成熟、先进、稳定的，扩展性好的技术架构```
1. 技术架构一般来说都根据不同的业务需求来决定的。框架!=架构。
2. 不采用微服务的话。单体应用存在的问题就扩展会整体扩展。而不是基于各个不同的服务。造成资源上的部分浪费。错误容忍性需要比较高的代码水平来实现。。。

先测试下是否本地电脑编译就很快？
同样慢的话。
```dockfile 镜像编译满 可以考虑分成不同的 stage 利用缓存```

可以考虑用一些 migration 的方式。比如 java 的 flyway 之类的。可以手动 trigger/自动随着部署 trigger 。
以及用户更改表的权限 revoke 吧。 保留修改数据的。所有更改表的都通过上面的 migration 的方式进行。

`还有个问题 你们有需要解决并发请求的吗 原本他们解决并发是同一套代码部署多个服务`
这不就是 k8s 帮你干的事情吗。。服务自动扩容/横向/纵向扩容。。

看起来你们需一个架构师来把服务微服务化+建立一套完整的 cicd 流程。
这个是一劳永逸的事情。之后别人只需要提交 pr. 等 review.合并。然后一键部署就好了。

@snake2004 项目见的权限控制可以放在不同的 repo 里面。
以及放在不同分支里就可以实现项目间的权限控制了吗。。。。

1. 一般来说 docker 和 k8s 都会上。docker 负责打包 image 。不需要 care 环境依赖啥的。k8s 主要做服务部署编排。。
2. poetry 比较多。
3. 一般来说是 rpc.服务间通信

以及针对你现在的问题：
服务太多管理与更新麻烦-> 如果每个服务环境都相互独立就不不会麻烦了。
使用 conda 进行环境管理-> 这个是在每个 docker image 里面建立不同的环境。所以不需要考虑环境切换的问题。
多个服务使用 http 进行通信，耗时有点长-> 体感上耗时长的话,可能并不是 rpc 能解决的问题。考虑下服务之间数据传输的合理性以及考虑下其他方式？

```不应该用多个分支来作为不同的 source of truth 。```

可以说下更多的 context 为啥要这么做。 写不同的配置文件不行吗。