关键需求
- 最大限度地提高团队的自主性：创建一个团队可以完成更多工作而不必与其他团队协调的环境。
- 优化开发速度：硬件便宜，人不是。使团队能够轻松快捷地构建强大的服务。
- 关注自动化：人们犯错误。更多的系统操作也意味着更多的事情可能出错。自动化一切。
- 在不影响一致性的情况下提供灵活性：让团队能够自由地为自己的服务做正确的事情，但是有一套标准化的构建模块可以长期保持健康。
- 为弹性而构建：由于多种原因，系统可能会失败。分布式系统引入了一整套新的故障场景。确保采取措施尽量减少影响。
- 简化的维护：而不是一个代码库，你会有很多。有准则和工具来确保一致性。
挑战:一次切换系统
- 从一个单一的体系结构切换到一个微服务体系结构是不是你可以一次完成的。如果你有一个单一的服务器，那么你可能会在其周围紧紧地建立一个存储库，部署任务，监视和其他许多事情。改变这一切并不容易。
- 如果一个公司从来没有使用微服务的经验，那么即使是一个绿地项目也会比他们想象的更难。
- 保留单片服务器，但是任何新的服务都是作为一个微服务来开发的，所以最终的东西都是从原来的服务器中流出来的，直到最终成为我们最老，最大的微服务。
挑战:拆分系统
- 自项目开始以来，如果将组件和服务粘合在一起，将其隔离起来可能相当具有挑战性。
- 您需要定义各个部分之间的交互和流程。如果你没有很好的定义，你的系统会产生更多的问题。
- 没有模式; 将系统划分为微服务有许多不同的规则，但是没有人会告诉你如何在应用程序中使用它。没有两个相同的微服务。
- 将整体系统分解成微服务的唯一方法是首先检查整体系统，以查看它最“伤害”的位置。系统的这些部分应该被取出并转换成微服务。
- 如果你没有适当的监控，你将不会看到你的系统是如何工作的。监视所有部分是如何工作的，以及他们在做什么。如果您监控您的系统，您可以轻松检测并解决问题。
- 渐进地，逐渐式是模块分离单片系统的最好方法。如果你想一次做所有事情，你一定会失败的。
挑战:组织认同
- 获得组织认同可能是最难的部分。
- 这不是一个技术决定。您需要清楚说明微服务架构的好处，以说服您的公司重新分配资源。在这样的变革被组织接受之前，这是一个漫长而乏味的过程，组织规模越大，决策的时间就越长。
- 说服你的组织改用微服务的最佳方式是将系统中的一个非关键部分转换为微服务。通过这种方式，您可以使用真正的，可用的微服务来展示其优势。
挑战:团队
- 团队本身面临着最大的挑战，因为它需要不同的思考。
- 开发人员必须花更多的时间来了解什么是端到端场景。他们需要熟悉这些技术，可能需要转换思维方式，这需要时间。
- 对于在一个可以进行端到端测试的世界中工作的人来说，这是不舒服的，现在你突然把它分解成小块。这更多的是文化上的变化。
- 从非常小的东西开始，在那里你可以真正受益，并选择一些不是你的应用程序的关键部分。获得一个小团队，并将应用程序的这一部分转换为微服务。证明它实际上是更好的，并逐步向组织扩展。
- 避免将整个系统一次切换到微服务。
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：人
- 服务团队开发，部署和运营自己的服务
- 团队在日常运营中应该是自主的
公众号：【架构师酒馆】