是微服务架构不香还是云不香？（转载自陈皓前辈的博客：酷壳coolshell）
有的人死了，他还活着。 —— 臧克家《有的人》
听闻陈皓前辈因心梗不幸去世的消息，心情非常复杂，再次感慨世事无常。
可能我说陈皓前辈大家会不太熟悉，那我说《左耳听风》相信很多人就知道了。对的，就是极客时间上《左耳听风》的作者陈皓，在2023年5月13日周六晚间离开了人世。真是让人痛惜！世界上又少了一位智慧的技术人才！希望各位程序员也要好好照顾好自己的身体，平安健康！！
我去访问了陈皓前辈的博客酷壳(https://coolshell.cn)，但发现有时候进不去，所以我就转载了陈皓前辈生前的最后一篇博文，表示对陈皓前辈的致敬。他走了，但他用短暂的一生留下了无尽的财富，这些宝贵的知识，是他生命的延续，相信他会活在千千万万技术人心中的。
是微服务架构不香还是云不香？（转载自陈皓前辈的博客：酷壳coolshell）
- 一、原文解读
- 二、独立思考
- 三、后记
- 如何访问
- 产品演示
- 介绍文章
- 四、原文链接
这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。
今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：
《微服务是不是个蠢主意？》
《单体回归？亚马逊放弃用于视频监控的微服务 》
《从微服务转为单体架构、成本降低 90%，亚马逊内部案例引发轰动》
看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……
一、原文解读
要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：
1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。
2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。
整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！
但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：
需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
AWS Step Function 按状态转换收费，所以，贵得受不了了。
注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。
然后，Prime Video 的团队开始解决问题，下面是解决的手段：
1） 把 Media Conversion 和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.
2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。
EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：
- 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
- 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。
二、独立思考
好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：
1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。
2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：
边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context（具体是什么 大家自行 Google），也就是一个业务域。
单一职责，高内聚，低耦合。把因为相同原因变化的合在一起（内聚），把不同原因变化的分开（解耦）
事务和一致性。对于两个重度依赖的功能，需要完成一个事务和要保证强一致性的，最好不要拆开，要放在一起。
跟组织架构匹配。把同一个团队的东西放在一起，不同团队的分开。
3）Prime Video 遇到的问题不是技术问题，而是 AWS Step Function 处理能力不足，而且收费还很贵的问题。这个是 AWS 的产品问题，不是技术问题。或者说，这个是Prime Video滥用了Step Function的问题（本来这种大量的数据分析处理就不适合Step Function）。所以，大家不要用一个产品问题来得到微服务架构有问题的结论，这个没有因果关系。试问，如果 Step Funciton 可以无限扩展，性能也很好，而且白菜价，那么 Prime Video 团队还会有动力改成单体吗？他们不会反过来吹爆 Serverless 吗？
4）Prime Video 跟 AWS 是两个独立核算的公司，就像 Amazon 的电商和 AWS 一样，也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维，我个人认为这个世界上再也找不到另外一家公司了，包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。
5）Prime Video 这个案例本质上是“下云”，下了 AWS Serverless 的云。云上的成本就是高，一个是费用问题，另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂，重写起来也很快，所以，可以很快使用一个更传统的“服务化”+“云计算”的分布式架构，不然，就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》（他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本）
三、后记
最后让我做个我自己的广告。我在过去几年的创业中，帮助了很多公司解决了这些 分布式，微服务，云原生以及云计算成本的问题，如果你也有类似问题。欢迎，跟我联系：haoel@hotmail.com
另外，我们今年发布了一个平台 MegaEase Cloud， 就是想让用户在不失去云计算体验的同时，通过自建高可用基础架构的方式来获得更低的成本（至少降 50%的云计算成本）。目前可以降低成本的方式：
基础软件：通过开源软件自建，
内容分发：MinIO + Cloudflare 的免费 CDN，
马上准备发布的直接与底层IDC合作的廉价GPU计算资源…
欢迎大家试用。
如何访问
中国区: https://cloud.megaease.cn
国际区：https://cloud.megaease.com
注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。
产品演示
https://www.bilibili.com/video/BV17v4y1R7mA/
介绍文章
欢迎使用 MegaEase Cloud
2023 年 03 月重大更新
（全文完）
（转载本文章请注明作者陈皓和出处 酷壳 – CoolShell ，请勿用于任何商业用途）
四、原文链接
https://coolshell.cn/articles/22422.html
是微服务架构不香还是云不香？（转载自陈皓前辈的博客：酷壳coolshell）相关推荐
- 微服务架构设计，对云原生的超越12因素了解吗，使用于所有语言！！！
微服务架构设计,对云原生的超越12因素了解吗,使用于所有语言!!! "超越 12 因素应用程序"12-Factor 为构建如下的 SaaS 应用提供了方法论: 使用标准化流程自动配 ...
- SWIFT PLM 介绍|基于微服务架构的Swift PLM云平台
基于微服务架构的Swift PLM云平台 1. Swift PLM 云平台基于微服务架构 杰信软件公司致力于一系列基于PLM系统的实施及二次开发的解决方案,并在近期取得巨大进展,自主研发了 ...
- 使用Spring Boot和Kubernetes构建微服务架构
"我喜欢编写身份验证和授权代码." 〜从来没有Java开发人员. 厌倦了一次又一次地建立相同的登录屏幕? 尝试使用Okta API进行托管身份验证,授权和多因素身份验证. 在本教程 ...
- 深析SpringCloud与Docker微服务架构
前言 微服务架构师当前软件开发领域的技术热点.它在各种博客,社交媒体和会议演讲上的出镜率非常之高,相信大家也听说过微服务这个名词.然而微服务似乎又是非常虚幻的--我们找不到微服务的完整定义,以至于很多 ...
- 基于微服务架构的云平台总体设计
正好这段时间我们在封闭研发我们的新一代数字化云平台(theplatform),借此机会和大家分享一下我们的总体设计及思路: theplatform是一款基于微服务架构的DevOps容器云平台,设计主体 ...
- 微服务架构下路由、多活、灰度、限流的探索与挑战
导语 2022腾讯全球数字生态大会已圆满落幕,大会以"数实创新.产业共进"为主题,聚焦数实融合,探索以全真互联的数字技术助力实体经济高质量发展.大会设有29个产品技术主题专场.18 ...
- 【微服务架构】一文读懂单片到微服务架构的模式和最佳实践
在本文中,我们将学习如何使用设计模式.原则和最佳实践来设计微服务架构.我们将使用正确的架构设计模式和技术. 在本文结束时,您将了解如何在微服务分布式架构上设计系统以实现高可用性.高可扩展性.低延迟和对 ...
- 使用Spring Security和OAuth 2.0保护Spring微服务架构
"我喜欢编写身份验证和授权代码." 〜从来没有Java开发人员. 厌倦了一次又一次地建立相同的登录屏幕? 尝试使用Okta API进行托管身份验证,授权和多因素身份验证. 每个开发 ...
- 日10亿级处理，基于云的微服务架构
德比软件:基于云的微服务架构 作者:朱攀,德比软件架构师,同济大学研究生,2007 年 2 月加入德比软件(DerbySoft),拥有 10 年以上的软件架构和开发经验.目前主要负责公司数据对接平台的 ...
最新文章
- Pytest - 使用介绍
- 漫谈流式计算的一致性
- ROS Gazebo（五）：ros_control和gazebo仿真总结
- 实战SSM_O2O商铺_06logback配置与使用
- 带指针C语言代码,C语言指针(示例代码)
- 你愿意隐姓埋名一辈子吗？
- Cocos2d-x移植Android 常见问题处理办法
- mysql 1016 145_Mysql中出现 errno:145的解决方法
- php 安装redis 扩展
- python的搜题软件下载_大学搜题用什么软件最好
- IBM SPSS Modeler 【3】 神经网络的生成
- hp服务器主板显示51,HP Jetdirect打印服务器故障解决
- 未转变者服务器bug,未转变者BUG问题解决 | 手游网游页游攻略大全
- 面试题 - 头条、京东
- mysql数据库基础评分标准_《MYSQL高级查询与编程》综合机试试卷 - 云南农职美和易思...
- Nginx服务器---正向代理
- 历经四个月，谷歌联盟的PIN码问题终于解决了
- php商城系统有什么优势？php商城系统具备的优势点介绍
- 运动助手卡密增加了，周卡来领取！
- 谱聚类算法入门教程（一）——Introduction