12.微服务设计 --- 总结

1.围绕业务建模
2.接受自动化
3.隐藏内部实现
4.让一切都去中心化
5.可独立部署
6.隔离失败
7.高度可观察1.微服务的原则它们主要描述了该如何做，以及为什么应该这样做的问题。这些原则可以帮助我们在构建系统时做出各种决定。1.1　围绕业务概念建模　围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好的反映业务流程的变化，使用限界上下文来定义可能的领域边界。1.2　接受自动化文化　微服务引入了很多复杂性，其中的关键部分是，我们不得不管理大量的服务。解决这个问题的一个关键方法是，拥抱自动化文化。前期可能会花费一定的成本，构建支持微服务的工具是很有意义的。自动化测试必不可少，因为相比单块系统，确保我们大量的服务能够正常工作是一个复杂的过程。调用一个统一的命令，以相同的方式把系统部署到各个环境是一个很有用的实践，这也是采用持续交付对每次提交后的产品质量进行快速反馈的一个关键部分。请考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使统一的方式进行部署的能力。考虑创建自定义镜像来加快部署，并且创建全自动化不可变服务器，这会更容易定位系统本身的问题。1.3　隐藏内部实现细节　为了使得服务独立于其他服务，最大化的独自演化的能力，隐藏实现细节至关重要。限界上下文建模在这方面可以提供帮助，因为它可以帮助我们关注哪些模型应该共享，哪些应该隐藏。服务还应该隐藏它们的数据库，以避免陷入数据库耦合，这在传统的面向服务的架构中也是最常见的一种耦合类型。使用数据泵或者事件数据泵，将跨多个服务的数据整合到一起，以实现报表的功能。尽量选择与技术无关的api，这能让你自由的选择使用不同的技术栈。1.4　让一切都去中心化　为了最大化微服务带来的自治性，我们需要持续寻找机会，给拥有服务的团队委派决策和控制权。在这个过程初期，只要有可能，就尝试使用资源自助服务，允许人们按需部署软件，使开发和测试尽可能简单，并且避免让独立的团队来做这些事。在这个过程中，确保团队保持对服务的所有权是重要的一步，理想情况下，甚至可以让团队自己决定什么时候让那些更改上线。使用内部开源模式，确保人们可以更改其他团队拥有的服务，不过这种模式需要很多工作量。让团队与组织保持一致，从而使得康威定律起作用，并帮助正在构建面向业务服务的团队，让他们成为其构建的业务领域的专家。一些全局的引导是必要的，尝试使用共同治理模型，使团队的每个成员共同对系统技术愿景的演化负责。像企业服务总线或服务编配系统这样的方案，会导致业务逻辑的中心化和哑服务，应该避免使用它们。使用协同来替代编排或者哑中间件，使用智能端点确保相关的逻辑和数据，在服务限界内保持服务的内聚性。1.5　可独立部署　我们应当努力确保微服务可以独立部署。甚至当需要做不兼容更改时，我们也应该同时提供新旧两个版本，允许消费者慢慢迁移到新版本。这能够帮助我们加快新功能的发布速度。拥有这些微服务团队，也能够越来越具有自治性，因为他们不需要再部署过程中不断的编配。通过采用单服务单主机模式，可以减少部署一个服务引发的副作用，比如影响一个完全不相干的服务。请考虑使用蓝/绿部署或者金丝雀部署技术，区分部署和发布，降低发布出错的风险。使用消费者驱动的契约测试，在破坏性的更改发生前捕获他们。消费者应该自己决定何时更新。1.6　隔离失败　微服务架构能比单块架构更具弹性，前提是我们了解系统的故障模式，并做出相应的计划。如果我们不考虑调用下游可能会失败的事实，系统会遭受灾难性的级联故障。当使用网络调用时，不要像使用本地调用那样处理远程调用，因为这样会隐藏不同的故障模式。所以确保使用的客户端，没有对远程调用进行过度的抽象。如果我们心中持有反脆弱的信条，预期在任何地方都会发生故障，这说明我们正走在正确的道路上。请确保设置了你的超时，了解何时以及如何使用舱壁和熔断器，来限制故障组件的连带影响。1.7　高度可观察我们不能依靠观察单一服务实例，或者一台服务器的行为，来看系统是否运行正常。相反，我们需要从整体上看待正在发生的事情。通过注入合成事务到你的系统，模拟真实用户的行为，从而使得语义监控来查看系统是否正常运行。聚合你的日志和数据，这样当你遇到问题时，就可以深入分析原因。而当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境是如何交互时，关联标识可以帮助你追踪系统间的调用。　12.2　什么时候你不应该使用微服务　第一个建议是，你越不了解一个领域，为服务找到合适的限界上下文就越难。服务的限界划分错误，可能会导致不得不频繁的修改服务间的协作，而这种修改成本很高。所以你不了解一个单块系统领域的话，在划分服务之前，第一件事情是花一些时间了解系统是做什么的，然后尝试识别出清晰的模块边界。从头开发也有很挑战。不仅仅因为其领域可能是新的，还因为对已有东西进行分类，要比对不存在的东西进行分类要容易的多。因此，请再次考虑首先构建单块系统，当稳定以后在进行拆分。12.3　临别赠言　做决策是一个更为常见的活动。建议你，尽量缩小每个决策的影响范围。这样一来，如果做错了，只会影响系统的一小部分。学会拥抱演进式架构的概念。在这个概念之下，系统会在你学到一些新东西之后扩展和变化。不要去想大爆炸式的重写，取而代之的是随着时间的推移，逐步对系统进行一系列的更改，这样做可以保持系统的灵活性。

12.微服务设计 --- 总结相关推荐

基于实战开发垂直搜索引擎_基于DDD的微服务设计和开发实战
作者:欧创新.邓頔.文艺你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务 ...
ddd 访问权限_基于DDD的微服务设计和开发实战
作者:欧创新.邓頔.文艺你是否还在为微服务应该拆多小而争论不休?到底如何才能设计出收放自如的微服务?怎样才能保证业务领域模型与代码模型的一致性?或许本文能帮你找到答案. 本文是基于 DDD 的微服务 ...
微服务设计指导-使用云原生微服务解决传统海量跑批时引起的系统间“级联雪崩”以及效率
问题描述这也是一起真实的生产事故,如下图所示这种"雪崩"是属于企业内部系统雪崩. 我们都知道如果是在外部http (包括一切restful.soap请求.http类型调用)调用 ...
华为18级大牛倾情奉送：分布式服务框架和微服务设计原理实战文档，啃完发现涨薪如此简单
前言分布式服务框架不仅仅包含核心的运行时类库,还包括服务划分原则.服务化最佳实践.服务治理.服务监控.服务开发框架等,它是一套完整的解决方案,用来协助应用做服务化改造,以及指导用户如何构建适合自己业 ...
阿里P8架构师20年经验总结成微服务设计企业架构转型之道笔记
前言本文涉及两个方面的知识体系,即企业架构知识体系和软件架构知识体系. 企业架构和软件架构虽然都与IT相关,但其知识体系是完全不同的两个领域.一般而言,搞企业架构的人士不明白软件架构的细节和实现,而 ...
《微服务设计》--读书笔记
追求卓越的承诺: 1.仔细复查代码微服务设计 <REST实战> <企业集成模式> 蓝绿部署或金丝雀发布版本管理 1.尽可能推迟 2.及早发现破坏性修改 3.使用语义化的版本 ...
规模化微服务——《微服务设计》读书笔记
改变思维的角度:故障无处不在当微服务规模化后,故障是无可避免的,以往我们总是想尽力避免故障的发生,而当故障实际发生时,我们往往束手无策.我们花了很多时间在流程设计和应用设计的层面上来阻止故障的发生, ...
康威定律和系统设计——《微服务设计》读书笔记
康威定律任何组织在设计一套系统时,所交付的设计方案在结构上都与该组织的沟通结构保持一致. --梅尔.康威如何理解这句话在软件工程上的含义?埃里克.S.雷蒙德说:如果你有四个小组开发一个编译器,那你 ...
安全——《微服务设计》读书笔记
身份认证和授权 1.单点登录(SSO) 当主体试图访问一个资源,他会被定向到一个身份提供者那里进行身份验证,身份提供者验明正向后会发消息给服务提供者,让服务提供者来决定是否允许它访问资源. ...
监控——《微服务设计》读书笔记
在单块应用的世界里,当我们遇到问题时,我们至少清楚从哪里开始调查.网站访问速度?网站访问异常?CPU占用过高?这些都是单块应用程序的问题,单一的故障点会极大地简化对问题的排查. 而现在我们面对了多个微 ...

12.微服务设计 --- 总结

12.微服务设计 --- 总结相关推荐

最新文章

热门文章