写点什么

微服务设计模式(上)

  • 2019-11-20
  • 本文字数:2197 字

    阅读完需:约 7 分钟

微服务设计模式(上)

微服务体系结构已经成为现代应用程序开发的实际选择。虽然它解决了某些问题,但它不是一颗银弹。它也有一些缺点,在使用这种体系结构时,有许多问题必须解决。这就需要学习这些问题中的通用模式,并使用可重用的解决方案来解决它们。因此,需要讨论微服务的设计模式。在深入研究设计模式之前,我们需要了解微服务体系结构的构建原则:


1.可伸缩性


2.可用性


3.弹性


4.独立的,自主的


5.分散治理


6.故障隔离


7.自动预配


8.通过 DevOps 持续交付


应用所有这些原则带来了一些挑战和问题。让我们讨论这些问题和它们的解决方案。

1 分解模式

a、根据业务能力分解

问题

微服务就是让服务松散耦合,应用单一职责原则。然而,将应用程序分解成更小的部分必须逻辑地完成。如何将应用程序分解为小型服务?

解决方案

一种策略是根据业务能力分解。业务能力是企业为了产生价值而做的事情。给定业务的功能集取决于业务类型。例如,保险公司的能力通常包括销售、营销、承保、理赔处理、开票、合规等。每个业务能力都可以被看作是一种服务,只是它是面向业务的,而非技术性的。

b、根据子域分解

问题

使用业务功能分解应用程序可能是一个很好的开始,但是您会遇到所谓的“上帝类”,它们不容易分解。这些类在多个服务中很常见。例如,Order 类将用于 Order 管理、Order 收入、Order 交货等等。我们如何分解它们?

解决方案

对于“上帝类”问题,DDD(领域-驱动 设计)起到了拯救作用。它使用子域和有界上下文概念来解决这个问题。DDD 将为企业创建的整个领域模型分解为子领域。每个子域都有一个模型,该模型的作用域称为有界上下文。每个微服务都将围绕有界上下文开发。


备注:识别子域并不是一项简单的任务。这需要对业务有所了解。与业务功能一样,子领域是通过分析业务及其组织结构以及识别不同的专业领域来识别的。

c、扼杀者模式

问题

到目前为止,我们讨论的设计模式是对 greenfield 的应用程序进行分解,但是我们所做的 80%的工作是对 brownfield 应用程序进行分解,brownfield 应用程序是大型的、单一的应用程序。将上面所有的设计模式应用到它们上是很困难的,因为将它们分解成更小的部分同时使用是一个很大的任务。

解决方案

勒死人的模式来了。勒死人的模式是基于一种藤蔓的类比,藤蔓缠绕着一棵树。这个解决方案很适合 web 应用程序,在 web 应用程序中,一个调用来回进行,对于每个 URI 调用,可以将服务分解为不同的域并作为独立的服务托管。我们的想法是一次做一个领域。这将创建两个独立的应用程序,它们并排放在同一个 URI 空间中。最终,新重构的应用程序将“扼杀”或替换原始应用程序,直到您最终可以关闭单片应用程序为止。

2 集成模式

a、API 网关模式

问题

当应用程序分解为更小的微服务时,有几个问题需要解决:


1.如何调用多个微型服务来提取生产者信息。


2.在不同的通道(如桌面、移动设备和平板电脑)上,应用程序需要不同的数据来响应相同的后端服务,因为 UI 可能不同。


3.不同的使用者可能需要不同格式的可重用微服务的响应。谁将进行数据转换或字段操作?


4.如何处理不同类型的协议,有些协议可能不受生产者微服务的支持。

解决方案

API 网关有助于解决微服务实现引起的许多问题,而不仅仅局限于上述问题。


1.API 网关是任何微服务调用的单一入口点。


2.它可以作为代理服务将请求路由到相关的微服务,抽象生产者的详细信息。


3.它可以将请求分散到多个服务,并聚合结果发送回消费者。


4.一刀切的 api 不能解决所有用户的需求;该解决方案可以为每种特定类型的客户机创建细粒度的 API。


5.它还可以将协议请求(例如 AMQP)转换为另一个协议(例如 HTTP),反之亦然,以便生产者和消费者能够处理它。


6.它还可以减轻微服务的身份验证/授权责任。

b、聚合器模式

问题

我们已经讨论了如何解决 API 网关模式中的聚合数据问题。然而,我们将在这里整体地讨论它。在将业务功能分解为几个较小的逻辑代码片段时,有必要考虑如何协作每个服务返回的数据。这种责任不能留给消费者,因为那时它可能需要了解生产者应用程序的内部实现。

解决方案

聚合器模式有助于解决这个问题。它讨论了我们如何聚合来自不同服务的数据,然后将最终的响应发送给消费者。这可以通过两种方式实现:


  • 复合微服务将调用所有所需的微服务,合并数据,并在发送回之前转换数据。

  • API 网关还可以将请求划分为多个微服务,并在将数据发送给使用者之前聚合数据。


如果要应用任何业务逻辑,建议选择组合微服务。否则,API 网关就是已建立的解决方案。

c、客户端 UI 组合模式

问题

当通过分解业务功能/子域来开发服务时,负责用户体验的服务必须从多个微服务中提取数据。在单片世界中,从 UI 到后端服务只有一个调用来检索所有数据并刷新/提交 UI 页面。然而,现在情况就不一样了。我们需要知道怎么做。

解决方案

使用微服务,UI 必须被设计成具有屏幕/页面的多个部分/区域的骨架。每个部分将调用单个后端微服务来提取数据。这被称为组合特定于服务的 UI 组件。像 AngularJS 和 ReactJS 这样的框架很容易做到。这些屏幕称为单页应用程序(SPA)。这使得应用程序能够刷新屏幕的特定区域,而不是整个页面。

总结

在本篇中,我们给大家介绍了分解模式和集成模式,在下篇文章中将会给大家带来数据库模式、可观测性模式和横切关注点的模式。希望对大家在理解微服务方面有所帮助。


本文转载自公众号 360 云计算(ID:hulktalk)。


原文链接:


https://mp.weixin.qq.com/s/j1Abgg7kIrbSe5hi7W4c4Q


2019-11-20 11:371228

评论

发布
暂无评论
发现更多内容

知识管理体系在企业中的作用

Baklib

什么是知识管理系统?如何改善客户体验?

Geek_da0866

【云原生】微服务SpringCloud-eureka(server)集群搭建

java李杨勇

Eureka spring-cloud 签约计划第三季

开源中国专访 TJ:开源许可证,欢迎来到云时代

tapdata

Tapdata 开源社区

C++继承中的对象模型与继承中构造和析构顺序

CtrlX

c c++ 面向对象 继承 8月月更

开源一夏 |分布式事务

六月的雨在InfoQ

开源 分布式事务 2PC 3PC 8月月更

多次拿下移动集团技术发明大奖,TA是怎么做到的?

鲸品堂

AI 资源

基于JavaSpringMVC+vue实现协同过滤电影推荐系统详细设计

java李杨勇

Java spring Vue 3 签约计划第三季 协同过滤

开源生态研究与实践| ChinaOSC

CCF开源发展委员会

leetcode 239. Sliding Window Maximum 滑动窗口最大值

okokabcd

LeetCode 数据结构与算法 双端队列

StoneDB 读、写操作的执行过程

StoneDB

MySQL 数据库 大数据 #开源 8月月更

备受资本市场关注的Zebec,正在构建“新DeFi”生态

小哈区块

架构实战营毕业总结

Geek_53787a

备受资本市场关注的Zebec,正在构建“新DeFi”生态

西柚子

中国开源先锋人物志 | ChinaOSC

CCF开源发展委员会

Hi,我是ChunJun,一个有趣好用的开源项目

袋鼠云数栈

超云

Kent Yao

超云 Supercloud

Redis 潜在问题

武师叔

8月月更

李斯特:不同流派的产品创新方法及创新误区丨创新工作坊

声网

灵感宝盒 RTE NG-Lab

CSS 移动光标使文本产生多个反差色特效

南城FE

CSS css3 前端 动画

RocketMQ高性能设计之动态缩扩容和消息实时投递

急需上岸的小谢

8月月更

【云原生】SpringCloud是什么?

java李杨勇

Java spring-boot 签约计划第三季

【云原生】SpringCloud-Spring Boot Starter使用测试

java李杨勇

Java web SpringCloud Alibaba 签约计划第三季

浅谈成功的企业知识管理

Baklib

移动端四种热更新技术对比

Geek_99967b

小程序

底层原理源码+面试场景还原,阿里巴巴多线程JDK源码学习笔记全网首次公开

程序员小毕

程序员 面试 多线程 高并发 jdk源码

开源知识库与SaaS解决方案的区别

Geek_da0866

“新DeFi”生态的构建,流支付协议Zebec或厚积薄发

BlockChain先知

开源一夏 |ModelScope--人像卡通化、人像美肤

六月的雨在InfoQ

开源 8月月更 ModelScope

因果决策从YLearn开始,数据智能基础软件迎“风口”

九章云极DataCanvas

人工智能 GitHub 数据智能 YLearn 工具包

系统入门-Linux系统基础命令

Albert Edison

Linux centos 指令 8月月更

微服务设计模式(上)_文化 & 方法_360云计算_InfoQ精选文章