害，用微服务，用啥语言都行。
不过 Elixir 肯定首推。

@wudalang123 你的意思是 不以为耻 反以为荣咯

什么时候见风就是雨的能这样逼逼赖赖，搬运都不考虑人版权，这种缺德事还是少干比较好。
笑贫不笑娼

最好再求一份代码。

这个已经很久没有法新版本了，都没人在维护了。

如果是 帖子 ID，你还是需要帖子的来源，这两个放在一起才能避免 A 平台的 ID 和 B 平台 ID 重复的问题。
如果存 历史数据，你在爬出来的时候可以对数据标题和内容进行摘要，把摘要值写进数据库去。
回到第一条，不要用帖子 ID，标题作为主键，应该对于标题或者内容进行摘要，这样你既能快速的判断内容是否一致，也能方便的存储历史版本。

网络调用过多
微服务的本质就是调来调去，这么个没错，如果你说的是那种 http call 的话，的确造成一些不必要的延时是没办法的

技术栈太过灵活
灵活是双刃剑啦

难于应对连表查询的需求
没错，里面还可能不止一种数据库，要查询怎么都麻烦

核心应用崩溃会导致大面积瘫痪
熔断，限流我觉得并不能有效的防治应用奔溃不能用的事实，最多也就是让你损失的不那么多而已。

运维成本增加
能不手动的就不要手动，实际上设立了统一 CI/CD 风格后只有好处没有坏处，写代码也更有信息

接口风格不一致
Convention over configuration，这点也是因为技术栈的不统一导致的很多问题，PHP 有自己的想法，Java 也有自己的想法。

微服务的出发点是好的，对于前端人员来说，其实需要的想要的结果，以及统一格式的返回，至于后面发生了什么，怎么协作的，他们并不需要去 care，你用 56 种语言都没有问题，他们要的就是你统一格式的 json 而已。
还有我一直不认为只用 SpringCloud 这种厚重的东西写出来的能叫做微服务。
对于服务提供的后端来说，有一个统一风格的 数据库 ORM DSL 也是一个很好的解决方案，因为那些业务就是查询来查询去，插来插去，这个时候当前后端不能统一的时候，就需要一个 MiddleMan 来干这些脏活累活，就是所谓的中台，提供聚合好的东西。

没有银弹的，Serverless 也不是。

如果是动态博客，用 Serverless+OSS 也是个不错的选择。成本算下来可能低一点。

我觉得吧，如果是静态博客，你大可以生成一遍上传到 OSS，绑定个自己的域名，没必要用什么服务器啊。

Serverless...

@luozic 缺点前两条并不认同，首先
> 1.纯函数式难以利用之前几十年大部分积累的面向对象的软件工程实践。

积累下来的实践并不是意味着最优解，很多也都是糟粕，就好比面向对象一半是显而易见的，一半显而易见是错的。

2. 纯函数式比较适合数据处理，不适合复杂业务建模。

> 模型本身不就是一个形式化的描述，函数式语言不是有更强的 DSL 吗。

Clojure 是个好语言，既有 JVM 平台优势，又有 Lisp 的优雅。
但是其实入门门槛高，并不适合所有人的。
小众语言不流行也是好事啊，物以稀为贵。

@ma836323493 函数式的特点难道不是 data as code 吗。

Bonjour. comment ca va.
Ca va bien, merci.

我觉得你能写出这个标题就觉得你能成大事

五个大猴子，一个小猴子路过
-。-

Rails 里面一般都是
test
dev
production
三个库
所以我建议加上一个 staging 的 数据库

Shure SE846，想买很久了。