纯文本还好处理点，你图文混排就有点麻烦。。。

生态差就是最大的坑点了。。。

格子衬衫完全没问题，看你怎么搭。。。

作为公司后端主力是 PHP （其实全是 PHP，只有个别无关紧要的部分我们刚开始尝试用 Go 重写）的人有话要说。

先说观点，即便没有 Docker、不用 k8s，甚至初期没有 API 网关，都可以往微服务的方向改造。改造这事本来就是根据自己公司实际业务情况和人员以及能力配置按需调整的个事。

我也不讲那么多发展的历史，就只说适合我们公司的情况。我们的后端原先是一个大的 Laravel 的单体应用，流量也没大的多吓人（但会有突发流量暴涨情况，确实不好扩展），然后基本随着业务需求慢慢堆叠越来越多的接口就是。本身业务也不算复杂，而且后端每次新增一些接口好像也不是什么复杂的事，比前端自由组合要快多了。

这样的事干了一年后，有点吃不消了，看看路由里记录的乱七八糟，过期的，臃肿的，重复的，极其混乱。然后性能问题当时也越来越多的暴露，但改起来就是动一发牵全身，烦躁的要死。

于是试图下放业务逻辑给前端——直到这时候，我还不知道什么是微服务…… 但我有一个直觉，后端经过一定程度的改造，将各个功能模块拆分开来，既便于扩展，又方便修改，还能给前端以更灵活的组合和调用，后端也可以稍微从繁重的业务逻辑里解脱开来，不需要做那么多重复的事情，更专注于改进架构，改善性能，提高交付速度。

甚至后端和后端之间都可以用网络通信的形式来做数据交互！

到这个时候为止，我仍然不知道什么是微服务。

但接下来，我就遇到了和楼主你同样的困惑。这玩意儿，耗费这么多网络通信，那性能、速度，还有和前端突然增加的那么多交互，怎么办？感觉会立马拖累性能啊。

然后这时候，也是微服务这个概念落地越来越多并且流行起来的前几年了。然后我就知道了有这么两个概念，用于包装微服务的接口，然后根据前端需求输入前端需要的业务接口。这个部分可以传统后端做，也可以前端侵入过来自己做，就是所谓的 Node 中间层。另外一个概念很关键的，叫 API 网关……

然后就突然豁然开朗，开始往自己想要的方向改造。

但进展并不顺利——比如经过试验，确实是容器化更适合微服务，而且几乎是必走的方向，对应的整个生态已经起来了。但我们公司小，破，我能力不过关，事务繁忙，所以一直推进的很慢很慢。另外一个方面，就是服务拆分了，拆分到什么地步最合适呢？原则上是最小化不可拆分的组件方可称为微服务组件，但现实中各种业务进度东搞西搞的，仍然有各种疲于奔命的情况，改造的也是拖拖拉拉，搞的并没那么细致。

还有个问题就是各个模块拆分开来了，可原先简单直连的数据库又有了新的问题。在改造过程中，就突然发现，居然不得不使用数据库连接池了…… 这不是什么新鲜东西，但我们公司是个小作坊公司，能力各种欠缺，整个转换的过程中也各种问题，所以现在只在新项目上用，老的项目还是一个粗暴的连接，对扩展很不利……

可即便这样，我还是在这个磕磕绊绊的过程中逐渐体会到了所谓“微服务”的好处。并不是这个概念本身如何，而是它带来的一个思想，我认为它本质上还是一种分层和分块治理。并不新鲜，但新项目从设计开始我就做了日后可以拆分的准备，同时在准备周边配套设施。当业务中有喘息的时间，同时根据之前上线的业务的经验，我就会推动将部分经过实际业务验证可行的功能模块做分析并拆分，一个一个服务独立出来。虽然还是进度慢，但总的来说，真的需要随着业务做扩展和改造，都不再是一个什么复杂的事。也不需要考虑之前那样一个大的单体应用多机部署的头疼问题，基本上根据监控结果对关键模块做拓展就可以，成本低，速度快，大家也省心……

说了半天其实不算什么微服务经验，只不过是一个同样是用 PHP 作为后端主力，也碰巧同样在用 Laravel 的人的一点感想。微服务是个好东西，但要做到理论上那种难度不小，工程量也挺大，周边配套需要一大堆。但这是个收益长远的事，我现在就享受到了多个项目复用一些功能模块和服务的好处——甚至某些独立模块可以改造后对外输出，给其他公司用，还没增加多少工作量…… 但整个迁移过程还是事满多的，我个人建议根据实际业务的需求来做，并不需要上来上那么大而全的微服务，把关键的，容易拆分的，复用率高的功能先逐个慢慢独立开来，慢慢尝试。有了第一个模块，有了 API 网关，你也可以说你开始微服务了。

哦还有个好处……微服务这个状态下，如果有的时候需要第三方公司或者外包介入协作，其实会更好处理。代码独立，功能独立，约定好接口和规范就可以……特适合我这种几个人的小作坊公司。但目前为止还没找过这样的外包……因为现在经过半年的改造，对自己人来说都业务压力会变小，可以承受，似乎没必要找外包了……

我觉得，首先可以先问一个问题——为什么你们要切到微服务去？

如果这个问题能回答的完整，其实已经知道大概从什么地方入手了……

不知道有的人何来的自信，张嘴就是没什么技术难度……

我甚至不用拿业界领先的 Dropbox 这样的标杆来举例，哪怕是国内一个赛过一个垃圾的网盘们，无论是内容存储，hash 匹配，文件切块，网络和带宽管理、内容运营等各个方面，有哪个是容易的？如果讲到增量同步这样一件事，做的出来和做的好又是天上地下，技术难度上也是云泥之别。

当然，不讲实操，只讲理论，那看起来是挺容易，业界相关论文和开源实现都一堆堆的，打包好的开源的网盘程序也一堆。但这样离做一个能正经运营的网盘还差太远了吧……

尤其是我们喷成翔的各家国内网盘，能做成那个鬼样，也不是没尽力，是这活真的没想象中那么容易。

要回应主题，倒是觉得可以先不管增量同步这事，把存储这事本身先实现好，前端都可以先凑合点。。

@aimerforreimu

其实几百的 CDN 费用也不算贵，而且这个量级对个人来说已经大到可怕了，对公司来说，反而这点钱又不是事。
而且不论个人还是公司，有这个级别流量几百块怎么也收得回来了哈哈哈。

但这个东西对个人确实还是有意义，蚊子肉也是肉，能不花钱就不花钱也是。。

我觉得这里搞清思路找到问题所在就好，但这个场景下造轮子真的是最没有必要的。。

1 效果没前端直传第三方好。
2 造一遍也是各种封装，还涉及 token 鉴权之类的，开发成本高。
3 你造出来也没人家好，从业务角度来说就不该考虑。
4 也不用担心第三方平台倒闭之类的。。。带宽足，成本低，一般倒的比别家公司还晚。。。

就知识可以学学，自己再试图强行搞定高并发下的图片上传，又费钱又费人还学不到啥。。。

@aimerforreimu 我想到了一个基于 nginx+redis 的方案，其实原理应该差不多。但控制权放在自己手里是这套的精华。

但我最想说的，好像七牛他们也不贵= =###

这个根节点的概念其实还是等于我有个主控空间，其他的那些图床可以当 CDN 来处理了。

这个概念挺好的，但本质上，我如果在 A 图床的图片失效了，即便后续在 B 节点更新了，但如果我其他地方有引用这张图的话……

哦，抱歉我没看上面流程图，其实访问还是从自己这边先预先走的。

同情楼主。

但我希望微信的办公功能再差点，再差点。

这样不知道能不能倒逼大家只把微信做聊天工具而不是办公茶品。

iPad 上文明才是正道 23333

@dong3580 那后来呢。。。

@jkm 中国国内也有 CDN ，体验上就是半天死活出不来页面，点了半天不能 update ，然而一旦 update 了—— 它跟疯了一样给你跑满速。

以及不止一位美国同行表示也时不时遇到抽风问题。

越来越觉得这问题是个人品走向的问题了。。

@jiezhi 不管谁的机器，上 100G+的内存都是不小的成本啊，这个很难借出来。

而且正常有 100G+的服务器，平时少说也跑了个五六十 G ，这一跑还得停掉原来的服务，成本上还是挺巨大的。

所以你还是应该自己去租个按使用资源收费的服务器……用完就关。

其实就算在 OS X 上 启动也不是秒开

@honeycomb 我意思是。国内根本就一直停在老版本的 Android 上，也没有 PlayStore 。

举报这事不是没用，但更多的程度上就是小圈子的自娱自乐，厂商甚至可以在不同的市场发不同的版本。

所以举报其实对改变现状没什么用，还是得靠资本的力量。但即便这样我也觉得不应该让这个成为国情，我不支持但也绝不反对别人的举报之类的行为，一点点的推动，哪怕推不动，别人至少推了，我绝不拦着。国内环境这么差，我们不能纵容厂商这种无耻的行为。

所以我用 iOS 去了，用实际行动说话。