微服务的分解和组合模式(1)

  使用微服务架构划分服务和团队是微服务架构实施的重要一步,良好的划分和拆分使系统达到松耦合和高内聚的效果,然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。

  在微服务架构的需求分析和架构设计过程中,通常是用领域的动词和名词来划分微服务的,在一个进程管理器中,可以分解为进程,应用,性能,网络,运行新任务,刷新等等,每一个名词和动词都可以是一个微服务,将这几个微服务组合在一起,就实现了进程管理器的整个业务流。

  拆分后,系统具有敏捷性、灵活性、可伸缩性等,拆分后有多个高度自治的微服务,那如何组合它们。

  1. 服务代理模式

  服务代理模式是最简单的服务组合模式,它根据业务的需求选择调用后端的某个服务。在返回给使用端之前,代理可以对后端服务的输出进行加工,也可以直接把后端服务的返回结果返回给使用端。

  做平滑的系统迁移,通常经历如下4个阶段。

    ①在新老系统上双写。

    ②迁移双写之前的历史遗留数据。

    ③将读请求切换到新系统。

    ④下调双写逻辑,只写新系统。

  服务代理模式常常应用到第3步,一般会对读请求切换设计一个开关,开关打开时查询新系统,开关关闭时查询老系统。

  2. 服务聚合模式

  服务聚合模式是最常用的服务组合模式,它根据业务流程处理的需要,以一定的顺序调用依赖的多个微服务,对依赖的微服务返回的数据进行组合、加工和转换,最后以一定的形式返回给使用方。

  这里,每个被依赖的微服务都有自己的缓存和数据库,聚合服务本身可以有自己的数据存储,包括缓存和数据库等,也可以是简单的聚合,不需要持久化任何数据。

  DRY:Don’t Repeat Yourself,在设计或者构造应用时,最大限度地重用了现有的实现。假如一块业务逻辑由三个独立的逻辑块组成,每个独立的逻辑块可能有多个使用方,则DRY原则推荐将三个独立的逻辑块封装成三个独立运行的微服务,然后使用本节的服务聚合模式开发聚合服务,将三个独立的逻辑块聚合在一起提供给上层组合服务。这样的设计原则有如下好处。

  三个独立的子服务可以各自独立开发、敏捷变更和部署。

聚合服务封装下层的业务处理服务,由三个独立的子服务完成数据持久化等工作,项目结构清晰明了。

  三个独立的子服务对于其他使用方仍然可以重用。

  参考:原文

原文地址:https://www.cnblogs.com/zhao-teng-ass/p/11055928.html

时间: 2024-08-02 11:37:28

微服务的分解和组合模式(1)的相关文章

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

微服务-分解应用程序从而实现更好的部署特性及可伸缩性

本文是我翻译INFQ上的一篇文章.作者Chris由简入深的讲解了微服务的来龙去脉.使用场景.优势劣势.以及现有技术栈向微服务架构的重构步骤.是一篇微服务主题的不可多得的好文. 原文地址:http://www.infoq.com/articles/microservices-intro?utm_source=infoq&utm_medium=popular_links_homepage#.U4-QbLLNKmI.gmail 微服务:分解应用程序从而实现更好的部署特性及可伸缩性 本文描述了越来越受欢

微服务架构(Microservice Architecture)

之前一段时间,有听部门架构说起接下来公司要使用微服务架构来研发系统,当时没怎么在意,因为是第一次听说微服务这个名词(果然无知者无畏啊):正好赶上五一假, 我自告奋勇的,接了编写微服务架构培训文档这个任务(也许因为我是文科生,文笔稍微好点).五一假期三天,基本都是在看资料,梳理思路以及编写接下来的培训文档中度过. 下面,就说说我这几天的一些收获吧:先说说资料来源吧:有架构给我的一些资料,以及自己百度和论坛.社区找来的一些资料,权当做一个总结式的简介... 目录如下: 一.微服务架构介绍 二.出现和

使用Spring Boot创建微服务

过去几年以来,"微服务架构"的概念已经在软件开发领域获得了一个稳定的基础.作为"面向服务架构"(SOA)的一个继任者,微服务同样也可以被归类为"分布式系统"这一类,并且进一步发扬了SOA中的许多概念与实践.不过,它们在不同之处在于每个单一服务所应承担的责任范围.在SOA中,每个服务将负责处理广范围的功能与数据领域,而微服务的一种通用指南则认为,它所负责的部分是管理一个单独的数据领域,以及围绕着该领域的相关功能.使用分布式系统方式的目的是将整体性的

使用Spring Boot构建微服务(文末福利)

本文主要内容 学习微服务的关键特征 了解微服务是如何适应云架构的 将业务领域分解成一组微服务 使用Spring Boot实现简单的微服务 掌握基于微服务架构构建应用程序的视角 学习什么时候不应该使用微服务 软件开发的历史充斥着大型开发项目崩溃的故事,这些项目可能投资了数百万美元.集中了行业里众多的顶尖人才.消耗了开发人员成千上万的工时,但从未给客户交付任何有价值的东西,最终由于其复杂性和负担而轰然倒塌. 这些庞大的项目倾向于遵循大型传统的瀑布开发方法,坚持在项目开始时界定应用的所有需求和设计.这

[转]微服务架构

本文转自:https://www.cnblogs.com/imyalost/p/6792724.html 资料来源:有架构给我的一些资料,以及自己百度和论坛.社区找来的一些资料,权当做一个总结式的简介... 目录如下: 一.微服务架构介绍 二.出现和发展 三.传统开发模式和微服务的区别 四.微服务的具体特征 五.SOA和微服务的区别 六.如何具体实践微服务 七.常见的微服务设计模式和应用 八.微服务的优点和缺点 九.思考:意识的转变 十.参考资料和推荐阅读 一.微服务架构介绍 微服务架构(Mic

微服务架构的设计模式(转载)

转载:原文链接 前不久,Java Code Geeks发表了一篇文章,分析单体应用与微服务的优缺点.近日,该网站又发表了一篇文章,提供了六种微服务架构的设计模式. 聚合器微服务设计模式 这是一种最常用也最简单的设计模式,如下图所示: 聚合器调用多个服务实现应用程序所需的功能.它可以是一个简单的Web页面,将检索到的数据进行处理展示.它也可以是一个更高层次的组合微服务,对 检索到的数据增加业务逻辑后进一步发布成一个新的微服务,这符合DRY原则.另外,每个服务都有自己的缓存和数据库.如果聚合器是一个

几种常见的微服务架构方案,2018年是否还一如既往的火

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm. ZeroC IceGrid微服务架构 ZeroC IceGrid作为一种微

【转】常见的微服务架构方案

背景: 工业领域,服务可能涉及多种语言,C++, Java,C#,python 最先考虑thrift,但thrift毕竟只是RPC框架,不包含服务治理的内容,且这个开源项目的维护状况并不算好,因此写个原型之后,仍然pass Zeroc Ice表现优异,基于RPC框架Ice,发展而来的IceGrid包含了完善的服务治理功能,服务发现.负载均衡.发布更新.事件通知... 商用软件,最近两年也开源了,靠服务收费,因此英文的技术手册还算是齐,但是离完善和问题解决还是有距离. 中文资料只一本2015年出版