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:人

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

原文发布于微信公众号 - 智能计算时代(intelligentinterconn)

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大数据的专栏

腾讯云分析支持微信告警啦!

在过去的一个月里,微信公众平台开放了图文分析等数据统计功能。眼尖的人也许早就发现,在微信公众平台的图文分析右上角,出现了"数据由 腾讯云分析 提供"字样. 通过...

2499
来自专栏IT大咖说

华为多年实践:ServiceComb在Service Mesh的探索与思考

内容来源:2018 年 6 月 27 日,华为微服务架构师田晓亮在“LC3微服务Workshop | 深入解读ServiceComb”进行《ServiceCom...

2764
来自专栏Rainbond开源「容器云平台」

当我们谈论监控时,我们在谈论什么?

1394
来自专栏知晓程序

微信新出的「功能直达」效果如何?我们采访了两家头部小程序

1795
来自专栏云计算D1net

公有云服务选择八大评测标准

说到选择一家公有云提供商,成本往往是首要因素。但是虚拟机迁移、存储和自动扩展等其他因素也应该加以考虑。 随着许多企业组织迁移到公有云或混合云,它们免不了要选择一...

3896
来自专栏ytkah

微信公众平台投票功能升级 可多渠道发布投票

  与之前同时发布公众号投票功能和多客服功能一样,昨天,微信公众平台投票功能升级的脚步紧随多客服功能正式向所有微信认证的服务号和订阅号开放,公众号运营者可通过群...

3604
来自专栏Java架构师进阶

怎么从初、中级Java程序员过渡到高级Java程序员?

原文地址:https://www.toutiao.com/i6599524702937416195/

1061
来自专栏机器之心

即将放弃Python 2.7的不止有Numpy,还有pandas和这些工具

36713
来自专栏携程技术中心

干货 | 携程酒店360度Java质量控制

作者简介 王幸福,携程酒店研发部资深测试开发工程师,负责酒店测试框架和测试工具的研发。技术狂热者,热衷于开源项目,利用创新去提高测试工作的效率。 一、前言 携程...

3454
来自专栏屈定‘s Blog

如何学习一门新技术

最简单的是找一个上手视频,因为视频是非常直观的展示了技术的使用.先学会用是最根本的,对于没有视频的技术的话,就可以搜索XX上手教程,XX学习记录之类的关键词,很...

1943

扫码关注云+社区