架构模式有哪些(redis有哪些架构模式)

架构模式(微服务架构概述)

一、导言

微服务是一种架构风格，大型复杂软件应用由多个微服务和前端表示层组成。系统中的每个微服务都可以独立部署，每个微服务都是松耦合的。每个微服务只专注于完成一个任务，并且完成的很好。在所有情况下，每个任务都代表一个小型企业的能力。
过去我们开发的应用都是单个应用(可以理解为一个部署包包含了项目的所有功能)。虽然开发部署方便，但后期随着业务的不断增加，单个应用的迭代开发、性能瓶颈等问题越来越明显，微服务是解决这一问题的有效手段。
要回答为什么使用微服务架构的问题，首先要了解集成架构。

二。什么是集成架构

顾名思义，集成架构将应用程序层打包到一个包中进行部署。为了让代码正常工作，集成应用程序的所有组件都是不可或缺的。

以一个典型的三层传统web应用为例，它由用户界面、数据库和服务器端应用组成。在这里，服务器端的应用程序称为monolith(集成或单个)，它包括表示层、业务层和数据层。所有代码都存在于同一个代码库中。为了使代码工作，它被作为一个单元部署。任何微小的变化都需要重新构建和部署整个应用程序。

单一应用架构

二。什么是微服务架构

微架构是一种架构风格，在这种架构风格中，整个应用程序被划分和设计为基于业务领域模型的松散耦合的独立服务。微服里的“微”很有欺骗性。事实上，它并没有指定服务的大小。

这里的重点是，每个独立的服务都有一个业务边界，可以独立开发、测试、部署、监控和扩展，它们甚至可以用不同的编程语言开发。

微服务架构

在基于微服务的架构中，理想情况下，每个组件或服务都有自己的数据库。如果没有集中式数据库，我们可以根据需要为每个单独的微服务使用NoSQL、RDBMS或任何其他数据库，这是使微服务真正独立的原因之一。

三。集成架构的问题

还是微服务架构解决的问题。

3.1难以扩展

集成架构应用程序只能通过将整个应用程序的多个实例放在负载平衡器后面来进行水平扩展。如果应用程序中的特定服务需要扩展，没有简单的选择。我们需要完全扩展应用程序，这显然会造成不必要的资源浪费。

相比之下，基于微服务的应用允许我们根据需要独立扩展单个服务。上图中，如果需要伸缩服务B，可以有10个实例，同时保留其他实例，可以根据需要随时更改。

3.2交货时间长

统一架构在单个应用程序的任何部分/层所做的任何更改都需要构建和部署整个应用程序。个别开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这影响了持续部署的效率。

但是在微服务架构中，如果一百个微服务中只有一个需要改变，那么只会构建和部署改变后的微服务，并不需要部署所有的。我们甚至可以在短时间内部署多次。

3.3应用程序复杂性

过去随着应用规模的增长(功能、功能等。)，团队也会相应的扩大，应用很快就会变得复杂和纠结。随着不同团队不断修改代码，慢慢的维护模块化结构变得越来越困难，慢慢的就导致代码像意大利面一样交织在一起。这不仅会影响代码质量，还会影响整个组织。

在基于微服务的应用中，每个团队做一个单独的微服务，代码会有序很多。

3.4所有权不明确

在集成应用中，看似独立的团队实际上并不独立。他们同时在同一个代码库上工作，并且彼此非常依赖。

在基于微服务的应用中，独立团队处理单个微服务。一个团队会有一个完整的微服务。工作的明确所有权清楚地控制了服务的一切，包括开发、部署和监控。

3.5故障级联

如果设计不当，集成应用程序一部分的故障可能会导致整个系统崩溃。

对于基于微服务的架构，我们可以使用断路器来避免这种故障。

3.6开发和运营之间的墙

开发团队通常进行开发和测试。一旦部署，维护和支持的所有权将移交给操作和维护团队。应用此时与开发团队无关，运维团队需要努力支持生产环境中的集成架构应用。

在基于微服务的应用中，团队的组织被理解为“构建它并运行它”，开发团队在生产中继续拥有应用。

3.7陷入某种技术/语言

使用集成架构意味着被实现的技术/语言所束缚。如果需要更改技术/语言，整个应用程序都必须重写。

有了微服务，每个服务都可以根据需求和业务使用不同的技术或语言实现。任何改变服务技术/语言的决定只需要重写具体的服务，因为所有的微服务都是相互独立的。

3.8支持微服务的正确工具/技术的可用性

几年前，我们没有合适的工具和技术来支持微服务。但是由于Docker容器和云基础设施(尤其是PaaS)向公众提供服务，微服务正在被大规模采用，因为它们提供了我们需要的“自由”，而不需要传统的配置过程。

四。了解微服务概要4.1微服务架构的优势

每个服务都足够内聚小，代码简单易懂，开发效率高。

服务可以直接独立部署，使连续部署成为可能。

每个服务都可以水平和垂直扩展，并且每个服务都可以根据需要部署到适当的硬件和软件上

扩展开发团队很容易，可以按照每个组件来组织。

提高容错能力，一个服务的问题不会让整个系统瘫痪。

该系统在很长一段时间内都不会局限于一个技术栈。

降低成本。尽量重用现有功能，避免重复制作轮子。可以大大降低项目建设过程的研究、设计、开发、测试、运营和维护的成本。

易开发易维护:一个微服务只关心一个具体的业务功能，所以业务清晰，代码少。独立开发和部署服务。

本地修改很容易，所以开发在线速度和灵活性。

更高的代码质量

围绕业务功能创建/组织代码。

提高生产力。开发者专攻自己的微服务开发，熟悉业务和代码。

更易于扩展

技术栈不受限制:每个服务可以使用不同的开发语言。

按需扩展:可以根据不同的需求实现细粒度的扩展。

打好多端服务的基础(多客户端，如浏览器、车载终端、Android、IOS等。).

应用程序的持续集成和持续交付极大地提高了生产力。要提高开发者的生产力，开发者只需要将代码推送到代码仓库即可。代码将被集成、测试、部署、重新测试、与基本功能(Maven依赖项)合并、质量审查，并准备好以极大的信心进行部署。减少了人工操作，大大提高了重复工作的效率。

4.2微服务的缺点

操作和维护的技术复杂性以及相应的操作和维护成本(测试、变更、部署)

必须建立开发运维一体化机制Devops。

必须有完整的监控手段和自动恢复手段。

数据库分区引起的业务数据同步和一致性问题

微服的界面会成为变化的敏感点(尽量保持界面稳定，不要频繁改变参与和参与)。

对运维要求高:服务意味着更多的运维投入。单个应用只需要保证一个应用的正常运行，而在微服务中，需要保证几十个、几百个服务的正常运行和协同工作。服务越小，独立性越好，但对应的服务数量越大。每个服务都需要独立的配置、部署、监控、日志收集等。，成本呈指数级增长。需要更高的自动化运维策略。

微服务应用作为一个分布式系统，带来了复杂性。当应用是一个整体应用时，模块之间的调用都是在应用内部，即使进行分布式部署，也仍然是在应用内部调用。但是微服务是多个独立的服务，模块调用的时候分发会比较麻烦。

对于多个独立的数据库，事务的实现更具挑战性。

依赖性管理是复杂的，

测试微服务变得复杂。当一个服务依赖于另一个服务时，测试需要另一个服务的支持。

五、直观体验微服务5.1微服务功能

微服务实现了以下功能:为vue开发的小程序和h5页面提供数据接口(即HTTP的访问地址)，可以查询编程语言的服务。
实现了以下微服务接口:

通过筛选条件查询：https://localhost:8888/v2/vue/api/programLanguage/getByName?language_name=P 返回：[“PHP”,”Python”] 无条件的全量查询：https://localhost:8888/v2/vue/api/programLanguage/getAll 返回：[“C”,”vue”,”java”,”PHP”,”Python”,”C++”] 另外一种条件查询方式：https://localhost:8888/v2/vue/api/programLanguage/getdetail/C 返回：{“laguage_name”:”C”,”star_number”:10,”desc”:”万物之源C语言。C语言于1969年至1973年之间由AT&T公司旗下贝尔实验室创建完成，用于构建Unix操作系统。C语言是一种通用型命令式计算机编程语言，其支持结构化编程、词汇变量范围与递归，同时亦是套能够预防各类未预期操作的静态类型系统。其最初构建目标在于编写系统软件。”}

5.2代码示例

以第一个接口https://localhost:8888/v2/vue/API/program language/get by name的代码为例。

@ApiVersion(2) //加入接口url的版本控制，http://localhost:8888/v2/vue/API/program language/get byname？language _ name = C @ request mapping(value = “/program language/get by name “)公共列表get by name(@ request param String language name){ List filter List = language List . stream()。filter(s -> s.toLowerCase()。包含(languageName.toLowerCase()))。collect(collectors . to list())；
返回筛选器列表；}

IDEA启动项目后，浏览器访问该地址查看效果。

访问效应

在Postman中调用微服务接口时，返回的Json数据经过了格式上的美化，更容易阅读。

邮递员

六。微服务拆分的策略6.0微服务拆分原则

1.单一责任、高内聚、低耦合:微服务边界内的业务能力要单一，微服务之间的耦合度要低；
2。微服务粒度适中:通过完成一个完整的业务需求来拆分微服务，不是越细越好；
(1)按业务模型切入:以业务模型中的业务活动为基本单元进行拆分，即微服务边界最大不能超过业务活动；
(2)进化拆分:在实际应用过程中，根据负载情况细化微服务拆分，实现性能升级；
(3)读写分离:将负责生成和维护数据的业务功能与负责查询和搜索数据的业务功能分离。
3。避免循环依赖和双向依赖:可以通过服务上移和服务下移的方式避免循环依赖，通过回调的方式避免双向依赖。
4。考虑团队架构:分为完成一个完整的业务逻辑所需的前中后端，便于开发团队单独实现。

6.1错误的政策

如果原有系统被完全颠覆，投入巨资启动“更大规模”的微服务系统来替代，会导致延迟(需要几年才能带来价值)和风险(超支，或者取消)。

6.2正确的策略

努力改变，而不是颠覆。尝试拆解一个小系统->培养能力积累经验->循序渐进在更大范围推广。

微服务拆分的核心需求：高内聚，低耦合，尽可能的减少微服务间的调用，尽可能的减少分布式事务； 微服务应该足够小，能够分配一个团队（5人左右）去实现，但也不能过细。

6.2.1总体思路

首先是业务分解，然后是领域建模。

6.2.1.1围绕边界上下文边界

服务应该根据业务能力而不是技术能力来划分。微服务应该首先通过有界的上下文边界来划分。注意:

理想情况下，有界上下文和微服务是1:1。

考虑到其他原则和实际约束，实际微服务的划分可以在有界上下文图的基础上进行合并。

服务微拆分的底线是聚合不能被打破，这会破坏事务一致性和业务约束。

6.2.1.2协调不同的业务变化率/相关性

微架构的目标之一是实现独立部署和发布，以便更灵活地应对业务和需求变化。在绑定上下文的基础上，考虑不同服务的变化率，将变化率相近的服务放入一个微服务中。
注意:

绝对费率:部分业务只在建设阶段变化频繁，维护期相对稳定；一些业务在可预见的未来会有持续的需求，变化频率很高。它们需要区分为不同的微服务。

相对速度:软件系统的响应性最终体现在需求的端到端交付周期中。如果两个服务之间的相关性相对较高，并且更改率接近，那么当业务需求到来时，总是需要同时修改两个上下文。需要将它们放入同一个微服务中。

6.2.1.3考虑系统的非功能性要求

微架构的一个优点是可以适应系统灵活伸缩的要求，更灵活地适应业务量的增长。设计微服务边界时，需要考虑非功能性要求:

可扩展性:有些服务在容量上有很大的弹性可扩展性需求(比如spike)，需要设计成独立的微服务。

可用性:有些业务对可用性要求极高(比如交易匹配)，需要设计成独立的微服务。

安全:有些业务对(数据)安全有独立的需求，需要设计成独立的微服务。

其他非功能性需求:微服务视角主要关注可扩展性、可用性和安全性，但其他非功能性需求在设计一个系统时也需要考虑。

6.2.1.4其他设计限制

复杂性
微服务在调试、部署、运维等方面会带来额外的复杂性和开销。将微服务粒度划分得太细是反模式的。考虑要解决问题的复杂程度，组合相对简单的服务。

团队
建议由一个独立的2 pizza团队(7+-2人)开发和维护一个端到端的微服务。团队过大或过小有时是服务拆分粒度不合理的标志。此外，还要考虑团队成员的能力搭配。

异构技术
一些遗留系统、业务软件包(如ERP)或技术组件(如搜索引擎)形成了一个天然的服务边界，很难被分解为微服务。

6.2.1.0战略设计阶段的详细说明

在电梯演讲模板中，定义了七个方面，引导团队思考产品本身的核心价值和愿景。最后才能做出流畅干练的描述语句。

6.2.1.1整理业务目标

站在用户的角度，了解用户的需求，确定如何为每一类用户群提供应对产品和服务的规划。

价值定位画布
价值定位画布是价值定位设计的经典做法。它描述了产品提供的价值是如何与客户的需求联系在一起的，以及客户为什么想要购买你的产品。
通过分析用户在工作中的成绩和痛点，找到需要提供的服务，明确产品的价值和意义。

价值取向画布

以内部员工的培训体系为例，梳理业务目标。

6.2.1.2场景梳理方法

是对核心用户和顶层服务的定性分析。同时也是从用户角度对问题领域的探索，产生问题领域中需要支持的分类和典型场景，以支持领域建模阶段。

场景排序步骤
第一步:从价值定位画布中选取一个问题域/业务；
第二步:参与者广泛思考所选问题域内的服务场景，可以粘贴便签；
第三步:收敛，整理发散的服务场景，得到场景分类列表。

场景组合方法

6.2.1.3过程组合和领域建模的例子

通过对业务和问题领域的分析，建立领域模型，通过边界上下文向上引导微服务的边界设计，通过聚合向下引导实体的对象设计。

领域建模

6.2.1.4边界环境设计示例

6.2.1.5微服务拆分的确定

围绕边界上下文进行调整。

设计因素1:在边际环境边界附近，
理想情况下，边际环境和微服务是1:1。
微服务拆分的底线是聚合不能被打破，这会破坏事务一致性和业务约束。

设计因素2:考虑系统的非功能性需求:安全性、可伸缩性等。

设计因素3:其他设计约束:复杂性、团队结构、技术异质性。

6.2.1.6分级模型

层次模型是层次技术架构在领域驱动设计中的体现。根据微服务的特点，根据实际业务和技术条件定义整体架构的分层，降低设计复杂度。考虑每个特定微服务中的层次结构。

6.2.1.7需求变化

七。微服务拆分模式7.1扼杀模式

陌生人模式类似于楼房拆迁，分阶段新建楼房后，逐步拆除旧楼房。

“陌生人模式”是在遗留系统的外围，以新的方式将新的功能构建到新的服务中。通过在新的应用程序中实现新的特性，并与现有系统保持松散耦合，随着时间的推移，新服务逐渐扼杀旧系统。从而逐渐取代原有系统。它适用于那些陈旧、庞大且难以改变的遗留系统。

“扼杀模式”有个别名叫“停止挖坑”，意思是不要在当前系统上增加功能，而是以松耦合的方式增加新的功能，让旧的功能慢慢被扼杀。这种模式的前提是确认遗留系统不会增加新的功能，只做Bug修复和日常维护。这样带来的改变风险最小，但是需要很长时间的进化。

绞杀模式逐渐取代旧系统。

7.2康复模式

修复者模式类似于文物修复。对一些有问题的建筑进行改建或修缮后，重新添加到原有建筑中，保持建筑原貌。

“修复者模式”是在现有系统的基础上，通过剥离新的服务和功能，逐步“释放”现有系统的耦合度，来解决遗留系统质量不稳定、bug多的问题。就像修房子或路一样，把要修的旧的部分隔离出来，用新的方式单独修。在修复的同时，要保证它还能和其他部分配合。修复模式适用于需求变化频率较低的库存系统。

一个运行5年以上的遗留系统，其中某个模块需要升级，我们单独将这个模块微服务到新系统，然后旧系统开始使用新开发的微服务。

还有一点需要注意的是，旧的应用和数据库都迁移到了新的微服务上！

好人模式

八。微服务转型的突破点

微服务接口开发难度从低到高依次为:
数据源维度
第三方接口->新业务数据库->旧业务简单数据库结构->旧业务复杂数据库结构->旧第三方封闭系统。
接口类别维度[/s2/]
单一查询接口->新增业务涉及新增、删除、变更查询接口->旧业务数据写入接口。

更多推荐

软件架构设计-软件架构风格，层次架构

企业架构| TOGAF架构能力框架

DDD兴起的原因及其与微服务的关系

微架构实现原理详解

10种常见的软件架构模式