• 如何使用微服务制造问题
• 微服务成本
• 理想的微服务平台

声称使用微服务架构的公司越来越多，一方面是云服务商的炒作，另一方面也的确是微服务带来好处的影响。 无论如何理解，在 twitter 上可以看到越来越多的程序员在吐槽微服务..

一方面，理论上微服务通过大事化小分而治之，可以解决开发周期长，旧项目难以维护等一系列问题，看起来非常万能。

另一方面很多人忽略了微服务的隐含成本，在实际实施后反而感觉处处不便。

实行微服务所需要的额外工作大致如下几类：

1. 部署困难：需要搭建如 K8s, CloudFoundry 等应用平台来解决
2. 测试困难：需要搭建 Jenkins 等 CI 工具来完成单元测试/集成测试
3. 运维困难：需要在应用平台上搭建监控和告警服务
4. Debug 困难：需要搭建日志服务接入平台，需要接入调用链分析工具
5. 代码维护：微服务化后可能有些服务长期无人修改，对每个服务都需要建立良好的文档

可以看到，实行微服务需要优秀的运维团队支撑起应用平台(k8s)、监控告警工具、CI 服务、日志/调用链服务。需要开发团队做好文档化、自动化测试。

这些工作在单一应用架构时经常会被忽略掉，但是微服务中如果没有这些工具 debug、运维 等工作会非常痛苦，会浪费掉团队大量时间。

所以微服务的先决条件是团队需要拿出精力来维护以上基础服务。

很多小团队选择使用微服务架构，但后果往往是花费大量额外精力去支撑平台，或在基础服务不完善的情况下浪费大量时间 debug，实在不是一个好的选择。而大公司实行微服务带来的好处则相当明显，因为人数众多，维护平台的消耗几乎可以忽略不计。

有野心的公有云服务商应该将自身作为所有中小企业的微服务平台，提供微服务架构的所有基础服务，大量降低使用微服务的成本。这样微服务才会成为真正通用的架构模式。

从功能上来说 AWS(国外的那个..) 最接近理想形态。已经真正的可以让中小企业完全基于 AWS 基础服务来设计自己的后台架构。而其他服务商还多以 VPS + 数据库的形态出现。

如果以支撑微服务架构为目标的话，AWS 为首的公有云还都有一定的距离。

不知未来哪一家有野心的厂商可以提供真正实用的微服务公有平台。