无锡中英文网站建设,wordpress如何去掉amp,wordpress匿名投稿,自己弄网站需要多少钱戳蓝字“CSDN云计算”关注我们哦#xff01;近期微服务的话题非常火爆#xff0c;有时可谓非常“疯狂”#xff1a;Netflix 在 devops 上做得很棒#xff0c;同时 Netfix 也采用微服务。因此#xff1a;如果我也用微服务#xff0c;那么我也可以在 devops 方面做得很好。… 戳蓝字“CSDN云计算”关注我们哦近期微服务的话题非常火爆有时可谓非常“疯狂”Netflix 在 devops 上做得很棒同时 Netfix 也采用微服务。因此如果我也用微服务那么我也可以在 devops 方面做得很好。很多情况下为了解决手头的问题我们付出了巨大的努力采用微服务模式但是并不清楚它的成本和收益。接下来我将详细介绍什么是微服务这种模式吸引人的原因以及它所面临的主要挑战。如果你正在考虑微服务是否适合你的模式我会在文章的最后用一系列简单的问题来帮你做出选择。 什么是微服务它为什么如此受欢迎首先从最基本的开始了解。下图是一个假想的视频共享平台的实现方式左侧是传统的整体式架构单个巨型单元右侧则是微服务 两种模式的区别在于第一种是整体式架构只有一个大单元。第二种则由多个小单元构成每个小单元都是独立的服务。上图已足够细致从中很容易找到微服务模式的吸引力所在。以下是微服务架构的具体好处独立开发小型的独立组件可由小型的独立团队构建。一个小组可以专门负责开发“Upload”服务不用去管其他服务。每个组件的功能变得简单这样一来开发人员了解组件的时间大大减少更容易开发新功能。独立部署每个单独的组件都可以独立部署。这样一来发布新功能的速度就更快风险也更小。假设“Streaming”组件修复了 bug 或者新增了功能那么部署时并不会影响其他组件。独立扩展每个组件可以独立地进行扩展。在新节目刚发布的繁忙时期可以扩展“Download”组件以支持增加的负载而不必扩展所有组件这样一来扩展更具弹性并且降低了成本。可重用性每个组件各自实现一个小的、特定的功能。这意味着它们可以很容易地适用于其他系统、服务或者产品。“Transcode”组件可以被其他业务单元使用甚至可以改写成一个新的业务从而为其他组提供转码服务。从以上细节层面可见微服务模式相比整体式架构的好处显而易见。如果确实是这样的话——那为什么这种模式最近才开始流行呢既然微服务好处多多为什么没有很早就开始流行呢原因有二。第一个原因是它提升了我们的技术能力另一个是最近的技术进步让我们能够把它带到一个新的水平。当我开始写这个问题的答案时发现一两句话无法解释清楚所以实际上我把它分成了另外一篇文章稍后再发表。因此在本文中我将跳过从单个程序到多个程序的过程忽略 ESBs 和面向服务的体系结构、组件设计以及有限的上下文等内容。在很多方面我们已经开始使用微服务随着近期容器技术特别是 Docker和集群技术如 Kubernetes、Mesos、Consul 等等的普及从技术的角度来看微服务模式变得更加可行。如果我们打算实施微服务那么在开始之前需要想清楚。从理论的角度我们看到了它的优点那么它有没有弊端呢微服务有什么问题微服务模式优点多多那么它的缺点是什么呢据我所知它主要有下列问题。开发的复杂性增加对于开发者来说事情会变得更加困难。当开发人员开发一个新功能时如果该功能依赖其他服务的话那么开发人员不得不在他们的机器上运行所有服务或者连接到这些服务。这通常比简单地运行单个程序更加复杂。这个问题可以通过一些工具得到部分缓解但随着构成系统的服务数量的增加开发人员在整个系统运行时面临的挑战也越来越多。运营的复杂性增加对于维护服务的团队来说潜在的复杂性是一个巨大的挑战。他们管理的服务不是简单的几个而是数十、数百甚至数千个正在运行的服务。服务数量越多通信链路就越多那么出错的可能性就会变大。devops 的复杂性增加以上两点表示开发和运营是分开进行的随着 devops 的普及我是 devops 的忠实粉丝devops 能够缓解这个问题吗如今有许多组织仍然依靠独立的开发和运营团队来工作而也有一些组织更倾向于采用微服务。对于已经采用了devops 的组织来说这仍然很难。既是开发者又是运营者已经非常艰难但是要建立好的软件却很关键了还得了解集群容器系统的细微差别特别是快速发展的系统那就更困难了。它需要资深专家如果开发团队成员都是专家级别那么结果可能会很好。但想象一下一个使用单一的整体式系统运行的不是很顺畅。如果增加系统的数量就会增加运行的复杂性。通过有效的自动化、监控和集群等技术可以做到。但瓶颈很少在于技术本身而在于找到能够有效使用这些技术的人。目前这些技能需求非常高可能很难找到。真实世界的系统往往界限不清当我们描述微服务的好处时经常谈到独立的组件。但是在很多情况下组件并不是独立的。在论文中某些领域可能看起来有限但是当你深入细节时你会发现他们比你预期的更具挑战性。事情变得非常复杂。如果你的界限没有明确的定义那么即使理论上的服务可以单独部署你也会发现由于服务之间的相互依存关系你必须部署一组服务。这意味着你需要一系列管理协同工作的服务版本这些服务版本之间的协作需要通过验证和测试你实际上没有可独立部署的系统为了部署新功能你需要仔细编排并同时部署许多服务。状态的复杂性往往被忽略在前面的例子中我提到一个功能的部署可能需要同时部署多个版本的多个服务。假设合理的部署技术可以缓解这种情况例如 blue/green 部署大多数服务编排平台可轻松应对或者并行运行的多个服务版本以及决定使用哪个版本的通道。如果服务是无状态的这些技术可以缓解大量的挑战。但是无状态服务非常容易处理。事实上如果你有无状态的服务那么我会倾向于考虑跳过微服务而考虑使用无服务器模型。实际上大多数服务都需要状态。比如我们的视频共享平台例子中的订阅服务。新版的订阅服务可以用新的形式将数据存储在订阅数据库中。如果你并行运行两个服务则一次运行了两个模式的系统。如果你进行了 blue green 部署而其他服务依赖于新的数据那么必须同时更新这些服务如果订阅服务部署失败并回滚则需要层级回滚。你可能会认为在 NoSQL 数据库中这些问题不存在但事实并非如此。不强制执行模式的数据库并不意味着它是无模式系统 - 它仅仅意味着模式在应用级而不是数据库级进行管理。理解数据的形状及其演变过程的挑战依然存在。通信的复杂性往往被忽略当你建立一个相互依赖的大型网络服务时可能会涉及到很多服务间的通信挑战随之而来。首先潜在的失败无处不在。假设网络调用失败了那么当一个服务调用另一个服务失败时它至少应当重试几次。服务之间的调用关系越多那么情况将变得愈加复杂。假设用户上传视频到共享服务中。那么我们需要运行上传服务然后将数据传递到转码服务此外还得更新订阅和推荐服务。所有这些调用都需要一定程度的协调如果失败就得重试。而重试逻辑可能很难管理。同步运行往往不是很稳定很容易失败。在这种情况下更可靠的解决方案是使用异步模式来处理通信。此处面临的挑战是异步模式会使系统具有状态性。如前所述分布式系统和状态系统很难处理。当一个微服务系统使用消息队列进行服务内通信时基本上会有一个大的数据库消息队列或代理将这些服务粘合在一起。虽然起初看起来似乎没什么问题但模式始终是一个隐患。新版本的服务可能会写入新的格式的消息当发送服务更改发送消息的详细信息时依赖于该消息的服务也需要更新。当然可以拥有多个不同格式的消息处理服务但数量一多就很难管理。当部署一个新版本的服务时两个不同版本的服务可能会处理来自同一队列的消息尽管消息来自不同版本的发送服务。这可能会导致复杂的边缘情况。为了避免这些边缘情况的产生最好是只允许特定版本的消息存在这意味着你需要将一组服务的版本作为一个整体来部署以确保先前版本的消息被适当地排除。这再次表明当你深入细节时会发现独立部署的想法可能与预期的有所差异。版本控制变难为了缓解前面提到的问题我们需要谨慎管理版本。遵循像 semver 这样的标准能够解决这个问题吗答案是否定的。Semver 是一个利器但是你仍然需要跟踪协同工作的服务和 API 的版本。这件事颇具挑战你可能自己都搞混不知道哪个版本的服务可以一起正常工作。在软件系统中管理依赖关系是非常困难的无论是节点模块、Java 模块、C 库还是其他东西。独立组件和单一整体之间的冲突很难处理。当依赖关系是静态并且能够进行修补、更新、编辑的时候挑战在所难免。但是如果依赖关系本身是实时服务那么你可能无法仅仅更新它们 - 你可能需要运行许多版本或者直到整个系统得到修复。分布式事务在需要跨操作交易完整性的情况下微服务可能会非常痛苦。分布式状态很难处理很多小的失败单元可能会很难进行集群操作。可以通过操作幂等性、重试机制等方法来避免这个问题这些手段在许多情况下能够起作用。但有些情况你需要保证操作的事务性要么成功要么失败而不能处于失败和成功的中间状态。在微服务模型中想要解决这个问题或者实现事务难度是很大的。微服务可能是一种变相的整体式模型单独的服务和组件可以独立部署但是在大多数情况下你将不得不运行某种集群平台比如 Kubernetes。如果你使用谷歌的 GKE 或者亚马逊的 EKS 这样的托管服务它们会帮你完成复杂的集群管理。但是如果你自己管理集群的话那么面对的是一个庞大而复杂的系统。虽然单个服务拥有前文提到的大量优点但是你依然需要非常小心。这个系统的部署、更新、故障转移等等操作起来都不是那么简单。在大多数情况下优点能够得到体现但是任然不要轻视或低估管理一个庞大而复杂的系统的难度。托管服务可能会有所帮助但这些服务大都刚刚新起例如亚马逊的 EKS 在2017年底才发布。微服务的狂热将开始降温仔细考虑避免加入对微服务的狂热追捧。为了帮助解决这个问题我已经注意到了一些你可能想问自己的问题并列举了问题的答案 点击下载 PDF 版本microservice-questions.pdfhttps://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf。不要把微服务和架构混淆没有微服务架构一说。微服务只是组件的另一种模式或实现。不论微服务是否在系统中使用它都与架构无关。微服务在许多方面与打包和操作的技术过程有关而与系统设计无关。组件边界仍然是工程系统中最重要的挑战之一。无论你的服务体量有多大是否在 Docker 容器中你都需要仔细考虑如何将系统放在一起。这里没有标准答案只是多一个选择而已。文章转自CSDN原文The Death of Microservice Madness in 2018链接http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/作者dwmkerr译者安翔1.微信群添加小编微信color_ld备注“进群姓名公司职位”即可加入【云计算学习交流群】和志同道合的朋友们共同打卡学习2.征稿投稿邮箱liudancsdn.net微信号color_ld。请备注投稿姓名公司职位。推荐阅读云计算到底是怎么玩的企业云存储建设之路AI in 美团吃喝玩乐背后的黑科技开除“野狗”式程序员团队的效率提高了Windows 成“弃子”Linux 终上位可替代Android的6大开源移动操作系统程序员求助被领导强行要求写Bug该怎么办网友的回答让我笑翻程序员抢票姿势 ↓交朋友还能抢票为交流学习请备注姓名公司职位学校专业点击“阅读原文”打开 CSDN App 阅读更贴心喜欢就点击“好看”吧
