对微服务的担忧

阿木子三不知 1年前 ⋅ 174 阅读

观测

  • 一个经历有趣和戏剧性创新的领域,解决在出错时如何知道某些事情是否出错 - 可观察性。对于单个进程,管理,调试和分析系统的原因比单个笔记本电脑上的单个代码库更难。能够在整个系统中进行分布式跟踪是必要的。事先想想,而不是事后。 
  • 一年前我担心网络视图需要更长的时间,但谷歌现在推动了ISTIO并且非常好。这已经处理了高度分布式网络中的通信。如何使微服务尽可能独立。不得不做很多事情。将由大型云提供商负责。 
  • 组织会误用,误解并且无法理解微服务的复杂性。如果不了解你想要达到的目标,那就试着做太多。小心咬掉比你能处理的更多。务实,并认识到微服务并不是解决每个问题的神奇方法。您需要善于监控,记录和诊断。如果没有监控,您将无法查看问题所在。 
  • 每个组织首先关注的是复杂性,增加复杂性的解决方案是增强自动化和操作可视性; 然而,微服务领域的这些产品类别是如此前沿,现实世界的实现包括使用各种各样的随机博客文章和纯粹的意志力将易变的开源计划连接在一起。这不是大型企业希望在其关键任务系统上休息的坚实基石。成功的计划需要经过深思熟虑的衡量方法。 
  • 从我们的角度来看,开发人员只是想弄清楚如何处理分布式解耦应用程序引入的一些挑战。曾经干净地包含在整体中的核心业务流程现在分布在许多不同的微服务中。了解这些业务流程非常重要 - 了解业务的当前状态,查看出现问题的时间,以便快速解决问题 - 但大多数微服务监控工具都是使用单一服务构建的  记住或专注于相对较短的调用堆栈,而不是长期运行的跨微服务流程。许多公司还没有开始考虑微服务对其核心业务流程质量的影响,这是一个在微服务架构完全进入主流之前需要解决的挑战。我们在一些客户身上观察到编排的微服务得到了大量宣传,这意味着微服务使用点对点或事件驱动的通信,并且经常完全忽略编排。这意味着工作流在运行时期间从事件链中出现。这些客户很快就忽略了他们的端到端流程,使得至少很难改变流程中的任何内容。监控这些流量也很难提供良好的可见度,这在操作过程中可能是有益的,也可以改善您的流量。在不违反服务自治和松散耦合的情况下,将正确级别的编排添加到组合中是非常有益的,但往往被忽视。

到期

  • 很多用户和客户都经历了最初的炒作,并且面临着诸如故障排除和理解性能异常之类的复杂性。我们有传统虚拟机过去没有看到的故障和错误。问题不容易确定,确定根本原因可能很难。这涉及微服务的整体复杂性。在生产中运行带有微服务的应用程序比我们想象的要复杂得多,而且我们面临着监控和故障排除工具缺乏成熟度的问题,这些工具延迟了投入生产的能力。
  • 当微小的组织采用微服务而不知道为什么或他们正在做什么,或者他们这样做是因为谷歌是。对于任何试图构建功能强大,可扩展的软件的组织来说,微服务都是很自 采用微服务的小商店因为渴望处于最前沿而不利。每位员工不需要10项服务。此外,术语使人们认为他们需要完全独立。我们需要独立的业务逻辑,而不是技术选择。以供应商中立的方式做出技术选择,以便供应商可以为您而战。不要让团队过于独立,因为这会导致供应商锁定。
  • 由于没有人监督标准,因此对定义有不同的定义或理解/解释。单片应用程序,服务应该做一个独立的功能。缺乏标准机构导致混乱。关于如何到达那里存在意见分歧。
  • 教条和派系是最大的。我们正在达到微服务已经成熟并且人们获得强烈意见的程度。变得太强大,忘记了为什么我们首先走上了这条路。专注于解决业务或技术问题而不是语义。所有事情都没有一个正确的答案。
  • 企业仍在尝试和学习如何使用和采用微服务。没有开发出足够的最佳实践。
  • 现在还早,但我们看到人们进入并挣扎。炒作已经上升,人们面临着关于权衡的艰难决定,他们需要评估微服务是否是正确的方法。构建云平台的应用程序,假设事情将失败,这是一个尽可能多的架构应该转向技术的领域。如何采用不同前提的新技术。

可扩展性

  • 人们看服务,拿起卡夫卡 - 它的工作,它很快。但随后他们开始遇到性能问题,因为它无法扩展。一旦你推动了500到1000个主题,你就开始强调Kafka集群了。要普遍存在这些类型的问题需要解决。卡夫卡有助于满足需求,但你会遇到问题。解决您业务中最佳方式的问题。

其他

  • 在不意识到安全隐患的情况下轻松提供微服务。微服务几乎给你带来腥味,因为它们是一次性的,人们会考虑明天重做而忘记它。
  • 不要急于将代码库重构为微服务,除非你以正确的思维方式负责地做到这一点并理解它所包含的内容。以正确的方法实施,否则您将得到强烈抵制,并回到单一的方法。
  • 很多炒作。人们正在意识到真正的挑战。我们的客户看到内部文化是主要挑战。适应面向业务能力的团队和敏捷技术。太细粒度的服务=成千上万的微服务。对于中小型组织来说,这是一场噩梦。
  • 微服务对于加速产品开发和上市时间非常有用,但人们担心服务的运营。推出服务既有趣又简单,但如果使用正确的工具无法正常运行,它们就会崩溃,并且每增加一个微服务,影响就会显着恶化。为了解决这个问题,公司急于采用数十种(如果不是更多)最佳点解决方案,这些解决方案彼此之间没有相互通信并导致更多混乱。GitLab作为一种产品,通过使用CI / CD管道作为单个应用程序中有效DevOps的网关,有助于为混乱带来一些秩序。

注意:本文归作者所有,未经作者允许,不得转载

全部评论: 0

    我有话说: