戳破微服务的七大谎言( 三 ) _微服务

另外，你试图省钱的做法可能会适得其反：

文章插图

快乐的云客户
5谎言五：微服务架构性能更高我在学校学到了一些经验法则：

读取内存所需的时间是读取二级缓存的 10 倍；
读取硬盘驱动器所需时间是读取内存的 10 倍；
从网络读取所需的时间是从硬盘读取的 10 倍。

这些数字是粗略的近似值。我们来看一下数据中心中的网络通信与从内存读取之间的实际差异：2009 年，从内存中顺序读取 1MB 的耗时估计为 250000ns；2019 年，在 AWS 数据中心中，两个 EC2 实例之间的通信速度可以达到 5Gbps 。
http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf
https://aws.amazon.com/blogs/aws/the-floodgates-are-open-increased-network-bandwidth-for-ec2-instances/
简单算一算：

2009 年的内存：0.25 毫秒内 1 兆字节；
2019 年的数据中心：1 秒内 5Gbit=1 秒内 0.625GBytes=0.64 秒内 1 兆字节

觉得差距不算大？可我们要意识到：

上面的网络速度是最好的情况；
我们正在对比 2009 年与 2019 年的指标；
要通过超高速的 AWS 网络发送这一兆数据，我们仍然需要从内存中读取它。

假设你只有一个依赖项，那么这也意味着几千倍的速度差距。实际情况中这一差距还会大得多。
难怪我们现在使用字节流来让每个请求快那么几毫秒。当然，对于字节流来说，调试服务间通信也是需要工具的。
6谎言六：管理多个服务并不难软件工程师喜欢自欺欺人。也许你以前听过，什么“不需要很长时间”“请给我几个小时”或“我可以在周末完成任务”，诸如此类。优秀的项目经理会理解这一点，并将工程师的估算值乘以四（或四十……）。
使用微服务的决策也会有同样的乐观情绪。这项工作并不是"为所有人获取 AWS 证书并移动一些代码"那么简单。实践中会有大量意外开销。下面是你需要的一些人员和工具类别：

架构师。你需要一些人来绘制美观且过于简化的图表并做演示。
发布管理。现在，你需要协调各个部署并管理多个 pipelines 。这种协调工作将需要通用工具链，还要有团队来维护这一工具链。
DevOps 。“常规”工程师既没有专业知识，也没有意愿来正确配置他们的服务。他们也很难正确处理安全性问题。
数据工程师。如果你很幸运能够按照这些建议来成功分解数据存储，那么你现在需要一个团队来将这些数据提取到一个地方进行分析。
配置文件。虽然一些额外的 YAML 文件听起来并不那么糟糕，但这里会出现最危险的错误。它们也难以测试和调试。

https://abcnews.go.com/Technology/wireStory/latest-twitter-Appears-back-outage-64276132
你不仅需要支付所有这些额外人员的薪酬，而且还指数级增加了工程组织中的沟通渠道数量。这会拖慢所有人的步伐。
7谎言七：如果你从头开始精心设计微服务，它们将会起作用这里我引用一段文字：

正常运作的复杂系统一定是从一个正常运作的简单系统演变而来的。从头开始设计的复杂系统永远无法正常工作，也无法靠打补丁来正常运作。你必须从一个简单系统起步。——Gall 定律

8总结既然有这么多如此明显的缺点，为什么微服务还这么受欢迎呢？
我相信大多数工程师（包括我本人）都有一定程度的自我能力否定倾向。很多时候，我们需要面对自身能力不足以应付的状况，却依旧要跨过眼前的障碍。在这种情况下，依靠他人的成果和“最佳实践”是更安全的。但是，我们很快就认为这些“最佳实践”是经过深思熟虑的，或肯定适用于我们的问题。当你启用更多服务时，云供应商会受益。微服务倡导者在你购买他们出的书时也会赚钱。他们俩都有动力向你兜售你本来用不到的技术。
不管怎样，我认为在某些情况下微服务可能是正确的选择。如果你是谷歌或 Facebook 那样的企业，并且要应对数十种产品上数以十亿计的活跃用户，那么单体架构肯定是不够的。如果你有大量可并行化的任务，那么只用单体也是不行的。
我的目的是要告诉大家，后端服务设计是非常重要的，没有哪种选择是银弹。无论我们是在谈论微服务还是单体，SQL 还是 NoSQL，Python 还是 Node，本质都一样。任何技术都不可能完美适应所有用例。