什么时候你不应该使用微服务
2016-06-26
最近几年我一直在微服务相关的工作，编码、学习模式、寻找并使用开源工具，到大会做分享…… 这本《微服务设计》我读起来还是有很多比较切身的感触的，这里记录下。
首先这本书最后一章有一段说的特别好，“你越不了解一个领域，为服务找到合适的界限上下文就越难……服务的界限划分错误，可能会导致不得不频繁地更改服务间的协作，而这种更改成本更高……”，软件行业从业者，尤其是那些已经不写代码的从业者，总会期望有银弹，但银弹终究是没有的，微服务也是。
我个人觉得微服务本质上是要解决一个 Scalability 的问题，这里的 Scalability 不仅仅是指应对用户量增加，还指业务复杂度增加，数据量增加，团队人员增加（具体参考《The Art of Scalability》一书）。微服务的一套方法论和具体实践方法给我们指了一条路，但路总是需要自己走的。
这本书的大量内容是对于其他书籍的提炼并用更现代化的语言阐述，例如，要理解微服务你不得不去阅读《领域驱动设计》（或者《实现领域驱动设计》），因为所有服务都是围绕领域来的；例如，要懂得如何应对大量服务的快速发布，你需要去阅读《持续交付》，再补充 Docker 相关的知识；例如，要学会如何保证大量服务交互时候的稳定性，你需要去阅读《Release It!》；此外，常见的分布式知识，如负载均衡、CAP理论，如何使用缓存，该学的你一样都不能拉下；对了，你还得知道 DevOps 以及如何监控你的系统和服务（可惜未见比较好的关于监控的书籍，有朋友知道的话请推荐）。
书中的第4，5章是我觉得比较有原创性的内容，怎么拆分一个巨型应用，第5章有很多切实的建议；而第4章告诉你，当你有一堆形状各异的服务的时候，他们之间集成可能会遇到什么麻烦，以及如何避免及应对。
不过，我不得不说，这书完全不适合编程新手阅读，因此书中几乎没有什么样例代码可以拿去实践的，而书中涉及了大量的开源工具，随便拉一个如 Hystrix, Dropwizard's Metrics 都可以去研究好几天，我是非常佩服作者的视野的。
没打五星的另外一个原因是，我读毕没有感觉啊哈！意思就是，书的结构并没有给我一个清晰的系统或者脉络，我自认已经实践过了书中六七成的内容，心中也没有一个清晰的系统抽象，本来指望这本书能有所帮助，然而还是失望了。
如果你在维护巨型应用并濒临死亡，那么还是应该走微服务这条活路的，但可以想象死而复生的道路比死亡本身难很多。