微服务提示和技巧

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

基于微服务的架构并不新鲜,但由于其强大而复杂的实践支持简化的应用程序开发和部署,突然成为人们关注的焦点。然而,从单一方法过渡到基于微服务的架构不仅需要技术专长,还需要组织的支持。在最近的 ActiveState 网络研讨会中,John Wetherill 和 Phil Whelan 讨论了一些提示和技巧,以帮助公司过渡到并充分利用基于微服务的方法。

查看下面的会议记录以及他们涵盖的提示和技巧的概述:

  • 从小处着手,快速行动 您需要从小处着手,组建小团队,因为大多数公司没有资源立即进行大规模更改。选择或确定一个您可以专注于并使其正常运行的小项目要有效得多。
  • 利用外部微服务/API 进入使用您无法控制或不了解其实现的 API 的心态。在使用现有应用程序自己开始使用微服务之前,先熟悉使用外部微服务。
  • 对齐开发/测试/阶段/QA/生产环境 使您的所有环境完全相同;你会避免很多问题。这适用于微服务和非微服务环境。
  • Steward API 构建和维护客户端库以访问微服务 API。否则,这些库的构建将留给第三方,当实施者错误地解释规范或不完全理解其调用逻辑时会导致碎片化。
  • 尽早利用可靠性要求 在开发过程中尽早确定可靠性要求,以便您设计和构建应用程序以遵循这些要求。然后,这些服务的消费者将更好地了解对可靠性、SLA 等的期望。可靠性绝不能是事后的想法。
  • 消除 IT 障碍 重点是赋予团队权力,而不是将微服务工作到具有现有障碍的系统中。我们需要一种不同的方法,其中 IT 支持 API——用户可以调用 API 来配置资源,而不是必须提交服务台票据才能这样做。
  • 准备永远保持向后兼容性将 新微服务与旧版本(最终可以删除)并排部署是很常见的。但是,在某些情况下,现场设备无法修补或更新。在这些情况下,必须保留向后兼容性。
  • 完成并不意味着已交付 不要在代码第一次交付后就撒手不管。开发团队应该在其生命周期内保持对它的兴趣。
  • 快速失败,快速恢复 失败总是存在的:拥抱并鼓励他们。如果进入破坏尽可能多的组件的过程,即使在生产过程中,您也必须开发恢复过程,以确保随后的系统更能抵抗故障。
  • 识别同步服务与异步服务 识别需要如何及早进行调用,以便您可以针对它们进行开发并将对性能的影响降至最低。
  • 最小化同步性 如果由于同步性而导致大量服务被阻塞,则很难优化效率和性能。围绕此构建系统以实时处理它。
  • 考虑功能标志 功能标志是启用或禁用服务的某些功能的开关。这些可用于通过设置或禁用标志来实时更改服务的行为。
  • 远离基础设施 不要将自己束缚在基础设施上。对于开发团队来说,底层基础设施是什么应该无关紧要。
  • 拆分和非规范化模式 跨多个应用程序/服务共享单一数据库的旧做法在微服务商店中效果不佳。考虑通过单独的服务共享数据,而不是跨多个微服务的通用模式,该服务可通过服务 API 访问。另一种选择是对数据进行非规范化并跨服务复制它。尽管这看起来有悖常理,但这些做法可以在应用程序交付中提供更大的灵活性和敏捷性。
  • 研究实践、工具、API、组件、模式 掌握该领域正在发生的事情,找到适合您需求的正确工具或流程非常重要。
  • 量化成功 如果你想说服公司的其他人微服务是必经之路,你需要衡量和量化你的成功。数字是你的朋友。
  • Monitor from day one 从第一行代码开始监控,到最后就不用处理了,会有其他压力。
  • 从第一天起就确保安全 您如何为系统打补丁?当漏洞出现时会发生什么?从一开始就为此进行规划和架构。
  • 从第一天开始扩展 当您让您的应用程序正常运行并且一切正常,然后意识到您将不得不每天响应数百万个请求时会发生什么?做好准备。
  • 从第一天开始就失败 试图阻止它是没有意义的,失败总会发生。计划并从中学习。
  • 从第一天开始就实现自动化 为了建立弹性并让团队快速行动,您需要自动化发布过程。否则,您将无法实现一天多次发布或让代码在持续集成管道中自由流动。
  • 权衡多语言与单语言 您应该能够使用最适合其解决需求的语言构建每个微服务,并且最适合构建服务的团队。另一方面,限制整个组织的语言选择以简化工具和知识要求可能是有益的。
  • 设计版本控制协议 以这样一种方式设计版本:如果任何消费者还没有移动到新版本,他们可以继续使用旧版本。使用不可变的服务架构意味着您可以不断推出新版本,让旧版本保持不变且不受影响地运行。
  • 赋予开发人员 权力 确保您的开发人员拥有足够的权力,因为他们需要能够构建系统、理解 QA 和部署过程,并参与软件交付过程的所有部分。
  • 准备好丢弃 微服务越细粒度就越容易丢弃或更改。
  • 尽早确定内部支持者 在您寻求将组织迁移到微服务架构的过程中,您需要盟友来帮助宣传。尽快在组织的尽可能多的层次上确定这些,并且在您能够衡量有形的积极改进(参见上一点)之后,确保将这些传达给支持者。你加入的人越多,过渡就越顺利。

我们希望您会喜欢本次网络研讨会并了解如何成功过渡到基于微服务的架构,并最终了解如何加速和创新您的应用程序开发。