本文摘要：
每个系统实现都市有一些错误的选择。可是他们所犯的最大的错误与他们的微服务实现无关。他们所犯的最大错误是在只有 20 名工程师的情况中实现了几十个微服务。 报表挑战 协调 Botify 是一家从事 SEO 优化的公司其平台于 2012 年在 Python/Django 技术栈上建立。 2016 年头整个 Botify 平台都是通过 Django 应用法式的负载平衡集群提供服务。 严格考察审慎行事 不能固然地认为微服务就是正确的选择。
每个系统实现都市有一些错误的选择。可是他们所犯的最大的错误与他们的微服务实现无关。他们所犯的最大错误是在只有 20 名工程师的情况中实现了几十个微服务。
报表挑战
协调
Botify 是一家从事 SEO 优化的公司其平台于 2012 年在 Python/Django 技术栈上建立。
2016 年头整个 Botify 平台都是通过 Django 应用法式的负载平衡集群提供服务。
严格考察审慎行事
不能固然地认为微服务就是正确的选择。
庞大性被转移但并未被消除
“我们公司也从单体转向了微服务但最后在二者之间找到了一个平衡点。
”
“我们公司也从单体转向了微服务但最后在二者之间找到了一个平衡点。”
另一个关键点 CVE 呢？谢天谢地你花时间在构建历程中引入了工具使你能够知道哪个服务受了影响因为为所有这些服务打补丁是很是难题的。
手工审计每一个服务将是一项困难的任务。只管如此因为一个 CVE 版本而部署 24 个服务是一种你没有真正思量到的痛苦。
![]()
为什么会做出这样的选择呢？Gergely Orosz 表现：“最早Uber 通过构建微服务来完成很小的需求或功效以至于泛起了许多由一小我私家构建维护的微服务。这些微服务的存在给我们带来了新的庞大性和挑战例如监控、测试、连续集成 / 连续交付（CI/CD）、服务级别协议（SLA）、跨所有微服务的库版本（宁静和时区问题）等等。
”
现在设计和构建某些比力大的特性需要花费更长的时间了。它们需要多个差别的服务来实现差别的功效并在差别的数据存储中协调更改。你会发现自己在差别的服务中复制了某些业务操作的逻辑只管你已经尽了最大的努力来保证每个服务在逻辑上是独立的可是你没法完全做到这一点。
这给表带来了种种差别的风险因为现在需要在服务之间保持业务逻辑的一致性。这是否意味着建立共享服务？手动保持逻辑同步？一声叹息。
重复
重复
性能挑战
最后稳定性开始泛起问题。
其中一个服务有点不稳定在会见它时会导致系统的其他部门挂起。现在你看到的不是抛出的错误而是请求悄悄地阻塞在那里直到失去响应。
你知道你的团队没有花足够的时间来确保服务之间良好的容错能力因此你意识到可能需要使某些交互异步举行这将进一步增加工程开销。
Netflix 是怎样做系统监控的？
译者 | 平川
4 月 6 日Uber 支付体验平台的工程司理 Gergely Orosz 公布推文表现其团队的架构偏向已经发生了变化放弃微服务转而使用宏服务。
4 月 6 日Uber 支付体验平台的工程司理 Gergely Orosz 公布推文表现其团队的架构偏向已经发生了变化放弃微服务转而使用宏服务。
要在正确的时间选择正确的解决方案来构建产物。
思量下你面临什么问题？
行业新趋势？这些公司微服务没用上 3 年就放弃了！
所以你决议从只有 20 人的工程师团队里抽出一大部门人和少量的工程承包人员一起在接下来的两年里重新计划设计你的应用法式拆分你的系统并构建出几十个微服务可能另有一些微前端。在新构建的应用法式上线后你很快就会发现部署确实越来越频繁。
每个微服务的代码库都很小推断也比力容易。小型的更新和 Bug 修复可以更快地完成、测试和上线。你对自己说：“太棒了！这肯定会提高开发团队的开发速度！”
我并不是说小型团队不应该把业务剖析为巨细合理的服务也不是说你不应该将那些功效过多的应用法式拆分。但多年来我看到太多的人提出这样的建议：把你的系统剖析成许多许多的小块就能神奇地解决你所有的问题。
我建议你严格地考察权衡。思量一下你的团队是否会从中受益然后从小规模实验入手拆。
本文关键词：金年会,金,年会,什么,你的,团队,没有,100人,那,金年会
本文来源：金年会-www.cigemarsh.com