最近比较热门的圈内话题，出了下云就是对微服务的讨论。

微服务今年又一次的引起了广泛讨论可能是源自今年年初亚马逊内部的一次架构迁移。

起因

在这个案例中，Prime Video 团队将一个监控系统从微服务架构迁移到单体架构，并避免使用昂贵的服务（如 AWS Step Functions 和 Lambda 无服务器函数），并对此举所带来的降本效果进行了评估。简单来说就是该团队通过将服务从微服务变成单体应用取得了明显的降本增效的效果。

这个例子引发了广泛的关注和讨论，一时间人们似乎不知道该如何去评价这件事情。反倒是一直鼓吹下云和反对微服务化的dhh（可以理解为著名网络喷子）一针见血，他指出：即使是亚马逊也无法理解无服务器或微服务。

讨论

事件逐渐发酵，目前关于逃离微服务的讨论可以频繁的见诸报端，比如前几天有人就这样的评价微服务

“microservices conflate logical boundaries (how code is written) with physical boundaries (how code is deployed).” “we propose a different programming methodology” “Our implementation reduces application latency by up to 15x and cost by up to 9x”

  • “微服务将逻辑边界（代码编写方式）与物理边界（代码部署方式）混为一谈。”
  • “我们提出了一种不同的编程方法论。”
  • “我们的实现可以将应用程序的延迟降低多达15倍，成本降低多达9倍。”

这里有一个非常有意思的点，那就是有没有一种可能单体服务比微服务其实要节省资源？

还有人认为微服务其实是一种权衡，并给出了下列的忠告。

  1. 谨慎地拥抱复杂性 投身于微服务不仅仅是一个技术决策，而是对复杂性的一种承诺。有时候，为了追随潮流，我们似乎在破坏一个系统。并非每个应用程序都需要一个相互连接的服务网络。正如Sam Newman在《构建微服务》一书中提到的那样，架构需要满足一定的前提条件，否则就可能过度设计。

  2. 灵活性是有代价的 是的，微服务承诺了灵活性，但也伴随着沉重的代价，不仅仅是基础设施方面的代价，还包括认知负荷。每个服务都变成了自己的领域，需要专门的关注。

  3. 没有一种大小适合所有 如果我从中获得了什么，那就是架构决策不能孤立地脱离业务需求而做出。一个灵活的初创公司的需求与传统的企业应用程序截然不同。虽然像Netflix那样的案例研究对我们启发很大，但我们必须认识到，适用于某个公司的解决方案未必适用于所有公司。

为什么

上面对于微服务的讨论完全是基于技术层面的，其实从成本角度我们可以更好的理解这个趋势。

之前技术公司蓬勃发展，人员不断壮大，这时候就需要把服务拆小拆细，因为拆分引入的复杂性就需要投入更多的人力进行开发和维护，因此服务越拆越小，团队规模越来越大，每个人都有活干，因此大家心照不宣的默认微服务是最佳实践，讨论比较多的就是微服务的优点，对于微服务的缺陷一般点到为止，毕竟喷微服务等于毁人饭碗。

现在整体经济不景气，大家为了节约资源开始八仙过海各显神通，比如下云，用自建机房去替代公有云服务。假如之前的假设：微服务比单体服务更消耗资源，是正确的话，那么转单体应用也能节约成本。另外各大公司近年来也是频繁裁员，人变少了，微服务引入的复杂性可能会被成倍放大，因此合服务也是顺理成章。指挥棒一换，对微服务质疑的声音也就多了起来。

twitter的实践

我们从twitter的实践可以很好的察觉到一些蛛丝马迹。最近twitter宣布进行了一些的优化，最终达到了降低成本的目的，其中就有。

从头开始完全重建了”For You”的服务和排名系统，导致代码行数减少了90%，从 70 万行减少到 7 万行，计算占用减少了 50%，每次请求中评分的帖子吞吐量增加了 80%。

这里猜测是不是有可能把微服务合成了单体服务，从而减少了大量的代码？

重构了技术堆栈的 API 中间件层，简化了架构，去掉了超过 10 万行代码和数千个未使用的内部端点，并消除了未被采纳的客户服务。

这里是删代码，也可能合了一些服务？

关闭了萨克拉门托数据中心，重新配置了 5200 个机架和 14.8 万台服务器，带来了每年超过 1 亿美元的节省。总共，X 平台释放了 48 兆瓦的容量，重新配置了 60,000 磅的网络梯架，然后将其提供给其他数据中心。

这里是换便宜的机房。

优化了 X 平台对云服务提供商的使用，并开始更多地在本地进行。这一转变使 X 平台的月度云成本降低了 60%。X 平台的工程团队所做的变化之一是将所有媒体/数据块工件从云中移出，这将其云数据存储大小降低了 60%，另外，该团队成功地将云数据处理成本降低了 75%。

这里是下云。

总结

  • 微服务有其存在的意义，特别是可伸缩架构带来的灵活性和诱惑力确实会让人欲罢不能。对于大团队来说微服务可能会利大于弊，不过对于小团队来说，微服务引入的复杂性可能难以克服，也许单体服务是更好的选择。

  • 没有最好的架构，只有适合自己的架构。

  • 下云和服务单体化在当前可能有节约成本的意义，但这些操作并不一定适合所有团队，还是要慎重对待。

  • 微服务将逻辑边界（代码编写方式）与物理边界（代码部署方式）混为一谈，当你写代码很难服务部署也很痛苦的时候，可以把这句话再三琢磨一下。