专栏首页超级架构师2017年终奉献:微服务最佳实践

2017年终奉献:微服务最佳实践

关键需求

  • 最大限度地提高团队的自主性:创建一个团队可以完成更多工作而不必与其他团队协调的环境。
  • 优化开发速度:硬件便宜,人不是。 使团队能够轻松快捷地构建强大的服务。
  • 关注自动化:人们犯错误。 更多的系统操作也意味着更多的事情可能出错。 自动化一切。
  • 在不影响一致性的情况下提供灵活性:让团队能够自由地为自己的服务做正确的事情,但是有一套标准化的构建模块可以长期保持健康。
  • 为弹性而构建:由于多种原因,系统可能会失败。 分布式系统引入了一整套新的故障场景。 确保采取措施尽量减少影响。
  • 简化的维护:而不是一个代码库,你会有很多。 有准则和工具来确保一致性。

挑战:一次切换系统

  • 从一个单一的体系结构切换到一个微服务体系结构是不是你可以一次完成的。 如果你有一个单一的服务器,那么你可能会在其周围紧紧地建立一个存储库,部署任务,监视和其他许多事情。 改变这一切并不容易。
  • 如果一个公司从来没有使用微服务的经验,那么即使是一个绿地项目也会比他们想象的更难。
  • 保留单片服务器,但是任何新的服务都是作为一个微服务来开发的,所以最终的东西都是从原来的服务器中流出来的,直到最终成为我们最老,最大的微服务。

挑战:拆分系统

  • 自项目开始以来,如果将组件和服务粘合在一起,将其隔离起来可能相当具有挑战性。
  • 您需要定义各个部分之间的交互和流程。 如果你没有很好的定义,你的系统会产生更多的问题。
  • 没有模式; 将系统划分为微服务有许多不同的规则,但是没有人会告诉你如何在应用程序中使用它。 没有两个相同的微服务。
  • 将整体系统分解成微服务的唯一方法是首先检查整体系统,以查看它最“伤害”的位置。 系统的这些部分应该被取出并转换成微服务。
  • 如果你没有适当的监控,你将不会看到你的系统是如何工作的。 监视所有部分是如何工作的,以及他们在做什么。 如果您监控您的系统,您可以轻松检测并解决问题。
  • 渐进地,逐渐式是模块分离单片系统的最好方法。 如果你想一次做所有事情,你一定会失败的。

挑战:组织认同

  • 获得组织认同可能是最难的部分。
  • 这不是一个技术决定。您需要清楚说明微服务架构的好处,以说服您的公司重新分配资源。在这样的变革被组织接受之前,这是一个漫长而乏味的过程,组织规模越大,决策的时间就越长。
  • 说服你的组织改用微服务的最佳方式是将系统中的一个非关键部分转换为微服务。 通过这种方式,您可以使用真正的,可用的微服务来展示其优势。

挑战:团队

  • 团队本身面临着最大的挑战,因为它需要不同的思考。
  • 开发人员必须花更多的时间来了解什么是端到端场景。 他们需要熟悉这些技术,可能需要转换思维方式,这需要时间。
  • 对于在一个可以进行端到端测试的世界中工作的人来说,这是不舒服的,现在你突然把它分解成小块。 这更多的是文化上的变化。
  • 从非常小的东西开始,在那里你可以真正受益,并选择一些不是你的应用程序的关键部分。 获得一个小团队,并将应用程序的这一部分转换为微服务。 证明它实际上是更好的,并逐步向组织扩展。
  • 避免将整个系统一次切换到微服务。

Best Practices:平台:

  • 您的平台是一套与支持工具相结合的标准
  • 微服务架构转换复杂性。 而不是一个复杂的系统,你有一堆简单的服务与复杂的交互。 我们的目标是保持复杂性可控。

Best Practices:服务要点

  • 独立开发和部署服务
  • 服务应该有他们自己的私人数据
  • 保持服务小到足以保持专注和足够大以增加价值
  • 将数据存储在数据库中,而不是短暂的服务实例
  • 最终的一致性是你的朋友
  • 尽可能将工作卸载到异步工作人员
  • 保持在一个共同的地方完成所有服务的帮助文档
  • 分配负载平衡器的工作
  • 网络边界上的聚合服务可以转化为外部世界
  • 分层安全,不要编写自己的加密代码!

Best Practices:服务交互

  • 通过HTTP传输数据,使用JSON或protobuf的进行序列化
  • 对于HTTP服务,500系列错误或超时意味着服务不健康
  • API应该简单而有效
  • 服务发现机制使服务很容易找到对方
  • 倾向于集权协调员的分散交互
  • 版本所有的API,在相同的服务实例中共存多个版本
  • 在服务超载之前,使用资源限制来快速失败
  • 连接池可以减少突发请求高峰对下游影响
  • Timouts最大限度地减少下游延误和失败的影响
  • 容忍不相关的下游API更改
  • 断路器在艰难时期给下游服务中断
  • 关联ID可帮助您跟踪跨服务日志的请求
  • 确保你能保证最终的一致性
  • 对所有API调用进行身份验证可以更清楚地了解使用模式
  • 使用随机重试间隔自动重试失败的请求
  • 只能通过暴露和记录的API与服务进行交谈
  • 经济力量鼓励有效使用可用资源
  • 客户端库可以处理所有的基础知识,因此您可以专注于重要的事情

Best Practices:开发

  • 为所有服务使用通用的源代码管理平台
  • 要么模仿开发或使用孤立的云开发环境
  • 推动工作代码经常主线
  • Release更少,Release更快
  • 警告:共享库很难更新
  • 您的服务模板应该覆盖基本原理
  • 简单的服务也很容易替换

Best Practices:部署

  • 使用系统映像作为部署包
  • 有办法自动将任何版本的任何服务部署到任何环境
  • 功能标志将代码部署与功能部署分开
  • 配置应该在部署包之外进行管理

Best Practices:运维

  • 在一个地方管理所有日志
  • 为所有服务使用通用监控平台
  • 无状态服务很容易自动扩展
  • 无法在您的平台上运行的相关服务也需要自动化

Best Practices:人

  • 服务团队开发,部署和运营自己的服务
  • 团队在日常运营中应该是自主的

本文分享自微信公众号 - 首席架构师智库(jiagoushipro),作者:Henry

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-12-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • [微服务架构 ] 微服务- 生存还是毁灭!

    上周,我谈到了作为一系列微服务开发的产品技术架构。谈话几分钟后,很明显团队已经支付了微服务高级版,但没有明显的投资回报。这组微服务是由一个由10名工程师组成的团...

    首席架构师智库
  • 微服务与SOA架构(2)

    服务分类学 服务分类学指的是在某种架构下服务是如何归类的。有两种服务分类的基本类型:服务类型和业务领域。服务类型分类法会根据整个架构中服务所扮演的角色进行分类。...

    首席架构师智库
  • 「微服务架构」七种微服务反模式

    流行语经常为进化的概念提供背景,并且需要一个良好的“标签”来促进对话。微服务是一个新的“标签”,它定义了我个人一直在发现和使用的领域。文章和会议描述了一些事情,...

    首席架构师智库
  • 微服务落地反思以及有效落地

    DevOps时代
  • 什么是微服务?为什么你要用微服务?

    最近几年微服务很火,大家都在建设微服务,仿佛不谈点微服务相关的技术,都显得不是那么主流了。

    phoenix.xiao
  • 低代码应用在腾讯TSF实现服务治理的解决方案

    导语:本文介绍了西门子企业应用开发平台Mendix应用在腾讯云微服务平台(简称TSF)实现服务治理的实践。该方案仅用于非生产环境的Mendix应用服务治理,如果...

    腾讯云中间件团队
  • 安防摄像机监控网页无插件视频直播综合管理平台EasyNVS如何对服务设备信息进行修改

    运维产品是平安城市发展到一定阶段的必然产物,用户花了大量经费来建设平安城市,随着前端、网络、存储、共享平台、实战平台、智能分析平台等建设的日趋完善,运行维护工作...

    EasyNVR
  • 微服务架构三十六计

    用户1682855
  • eShopOnContainers 知多少[4]:Catalog microservice

    Catalog microservice(目录微服务)维护着所有产品信息,包括库存、价格。所以该微服务的核心业务为:

    圣杰
  • 基于 Docker 和 Kubernetes 的微服务实践

    微服务 是将单一的应用程序拆分成多个微小的服务,各个小服务之间松耦合,高内聚,每个小的服务可以单独进行开发,不依赖于具体的编程语言,也可以使用不同的数据存储技术...

    Java帮帮

扫码关注云+社区

领取腾讯云代金券