讨论go-zero和kratos怎么选

不用微服务，数据量大了扛不住，用单体的分布式集群还是

0到1的项目，初创项目用gin就可以了，这个阶段考虑微服务，只会让团队大量精力资源被构架，基础设施占用，最终导致项目失败，另外你知道单体qps上限是多少么？硬件跟得上，一般的项目都没问题，后期真的业务量上来了，招兵买马，改造成单体都不是问题，另外微服务并不是非要用这些框架，直接gin grpc 注册中心就能搞，没必要用那些框架。

目前用的java做的分布式，一天几十万新增数据，要到极限了，觉得重构不如换go了

目前用的java做的分布式，一天几十万新增数据，要到极限了，之前表也没有设计好，分表很麻烦，觉得重构不如换go了，

1. go这边以简单架构为目的，java那边尽量往复杂架构走；
   技术转型或者创业阶段，尽量简单，先把项目做出来。 用太复杂的架构容易死；
2. 每天新增几十万，其实不算多，甚至不用考虑分表，做一个主从读写+redis完全能撑得住了；
3. 从架构上说，把一个大单体拆分成多个小单体(用户服务、管理后台服务、订单服务、报表服务)也比拆成微服务好维护。
4. 单以接口来说，理论上微服务的性能比单体要差很多，因为链路变长了，多了服务发现和grpc调用；
5. 我现在维护一套微服务： 一个人 + 三台服务器，真的好麻烦，如果是传统的gin + http, 只需要两三个进程就行了，现在要维护30多个进程，而且三台服务器跑的进程都一样，根本做不到单台服务器跑某个进程；

直接用gin写一个单体吗，所有模块都在这个单体里，然后用把单体做成集群；还是一个单体一个模块，然后做分布式http相互调用

一开始不用考虑那么多，先实现功能：
所有模块都在这个单体， 用nginx做负载均衡

最早版本的java写一起了，看到您这么说，也不想整微服务了

不知道你们的业务是什么，你们搭建可观测性了么？如果仅仅只是数据问题，瓶颈在数据库上，可以调研其他的数据库，每天这么大量是iot还是什么数据，iot可以用时序数据库，这点量不算啥，要是qps太高了可以试试加内存或者升级u，项目重搞，还是不太建议，当让我不知道你们具体业务和具体情况，也无法给出太多建议

从0开始搭建，要对go非常精通吧

不需要精通。这样其实少了很多心智负担，学你说的这两个框架入门时间长啊。其实没必要。我给公司纯go原生写的服务，每日处理数据量1200w，跑的好好的。

go的标准库写得太强了，强的一般的项目没必要上框架

您写的是单体还是微服务哈，比如用户是一个单体，订单是一个单体，然后他们之间相互调用

用户是一个单体
订单是一个单体
然后他们之间最好不要相互调用

不是相互调用模块，这样单向访问对吗，比如：真实用户->订单单体->用户单体，拿到用户信息->订单单体响应->真实用户，还是API直接写个单体，去分别调用他们两个

数据库尽量共用一个，不要分成：订单库、用户库。
在共用数据库的前提下，无论是订单单体 和 用户单体，他们都能做到，不调接口就能得到想要的数据；
但是：
我一般不会用这样的架构，没必要，除了代码层面做到隔离，在性能方面起不到太多的作用，假如真的压力太大，再启动一个大单体负载就行了。
我一般这样划分服务：
api-server: 对外提供给客户端的接口服务
admin-server: 管理后台的接口服务
task-server: 做脏活的服务

用户 订单 之类的全部在一个大单体里面吗，然后做大单体集群