@mark2025

还是有不通的，单体服务你不知道这个接口别人用了没有，界限是模糊的。
而微服务你已经明确定义了哪些是外部的，哪些是内部的。你动内部的，是没有问题的，你动外部的，你需要做兼容处理，或者增加一个新的接口，或者发布一个新的版本。

看看我的需求：

1 ，解决耦合度增加导致的复杂度增加的问题，采用微服务可以物理隔离各类模块的联系。
2 ，微服务后可以按模块部署，更容易按需迭代扩容。

从维护角度分析：
复杂度管理：微服务虽然看起来更多了，但是出问题的时候就更容易定位了。
水平扩展性：性能问题更容易定位，也更容易扩展。


从写代码角度管理：
写代码时由于粒度更小，更加容易写出稳定，可测试的代码。
开始项目前必须考虑通信，性能等因素，进一步要求先设计后编码，有利于提高代码质量。


为什么要微服务？回到第一性原理回答：

1 ，因为人的脑袋存储和 cpu 不够大，不能同时装下那么多模块的逻辑；
2 ，因为一台或者几台机器不够，不能同时运行这么多服务；
3 ，因为我们需要保证服务的不间断运行。


为了看看我的答案怎么样，我问了下 deepseek r1：为什么要微服务？用第一性原理回答

结果还好，无明显遗漏。。。

@dyyhobby

最近一个项目打算转 go 了。因为业务今年到去年增长了 10 倍。

使用 go 是因为想搞微服务，主要解决耦合度增加导致的复杂度增加的问题，采用微服务可以物理隔离各类模块的联系。
另外微服务后也可以按模块部署，更容易按需迭代扩容。

滴答清单年会员你值得拥有

不可能的，牛散比清北概率小。

概率上：几十年出了几十个牛散，和中彩票差不多。

我鼓励我们前端对于设计和产品的不合理和不美观，互相反馈(ds)下。

而且你看的不是一个级别东西。

react 是一个主要面向开发者的库，专注的是开发体验。
request 也是一个开发库，专注开发体验。

这两个东西需要文档。。。


git 包大部分代码专注于数据结构和流程，体验在命令行接口那块。

因为你看的：

一个是 doc ！

另外一个是代码注释！

一个是写文档的时候特别写的，一个是写代码是顺便写的。


你应该问：

问什么多 go 项目没有专门文档(doc)，那么回答可能是因为 easy ，看数据结构就行。

没有，为啥不给钱搞简道云，易搭之类的。

如果还没有用钉钉，那么可以考虑钉钉和企业微信。

能省很多事情，如果是专业人士 n8n,NocoDB 之类可能适合。

@zhouyin

莫非你以为大家没用过。

1 ，pg 有 pg_fwd,mysql_fwd 等等扩展，可以直接调其他数据库的数据源；
2 ，装上时序扩展变身时序数据库(timescale 等)；
3 ，装上矢量扩展变身矢量数据库(pgvector)；
4 ，装上图扩展变身图数据库（如 Apache AGE ）；
5 ，装上分析扩展变声分析型数据库(duckdb 等)；
6 ，装上认证扩展和 rest 扩展直接变身 api （ superbase ，pgrest 等）；
7 ，可以装上词库扩展变身搜索引擎（ jieba 等）；
8 ，装上 no scheme 扩展变身 mongodb(如 hstore );
9 ，装上列扩展变身列数据库（如 Hydra ，cstore ）；
10 ，支持用其他语言写存储过程；
12 ，其他地理位置，jsonb ，gin 索引，物理视图等等不一一列举，几百个扩展你可以搜索到的。



虽然你大部分的用不上，但是万一用得上的时候呢？

稳定，可扩展，使用阿里云等 pg 服务后，pg 和 mysql 一样简单，所以为什么不用呢？

我用 debian 没挂？

那么必须是扩展有几百个的 pg 啊。

装一个扩展，就变身了！！！

还有迪士尼的也是啊

定位比较好：


什么魔童，熊出没，帕丁顿熊。。。


别人卖两张，他们一卖就是三张四张！！！

阁下何故如此，成仙路并未断，而是变成人人可修仙了。

难道我们开发程序不是为了做产品，赚取高扇出的价值吗？现在有工具让我们能更快的出产品，那么就好好利用，赚他一笔！

@sunny352787

centos 那还得从红帽子开始说起。

@tlerbao

新出的 2.0 增加了上下文感知能力，作为免费的，还是不错的。