锐客网

  1. 首页 > 生活百科 > >

微服务架构概述 架构模式

生活百科生活知识

架构模式(微服务架构概述)
一.导言
微服务是一种架构风格，大型复杂软件应用由多个微服务和前端表示层组成 。系统中的每个微服务都可以独立部署 ， 每个微服务都是松耦合的 。每个微服务只专注于完成一个任务，并且完成的很好 。在所有情况下，每个任务都代表一个小型企业的能力 。以前我们开发的应用都是单个应用(可以理解为一个部署包包含了项目的所有功能) 。虽然开发部署方便 ， 但后期随着业务的不断增加，为了响应业务需求 ， 单一应用的迭代开发、性能瓶颈等问题越来越明显，微服务是解决这一问题的有效手段 。要回答为什么要用微服务架构这个问题，首先要了解集成架构 。
二、什么是集成架构？
顾名思义，集成架构将应用程序层打包到一个包中进行部署 。为了让代码正常工作，集成应用程序的所有组件都是不可或缺的 。
以一个典型的三层传统web应用为例，它由用户界面、数据库和服务器端应用组成 。在这里，服务器端的应用程序称为monolith(集成或单个)，它包括表示层、业务层和数据层 。所有代码都存在于同一个代码库中 。为了使代码工作，它被作为一个单元部署 。任何微小的变化都需要重新构建和部署整个应用程序 。
单一应用架构
二、什么是微服务架构？
微架构是一种架构风格 ， 在这种架构风格中，整个应用程序被划分和设计为基于业务领域模型的松散耦合的独立服务 。微服里的“微”很有欺骗性 。事实上，它并没有指定服务的大小 。
这里的重点是，每个独立的服务都有一个业务边界 ， 可以独立开发、测试、部署、监控和扩展，它们甚至可以用不同的编程语言开发 。
微服务架构
在基于微服务的架构中，理想情况下，每个组件或服务都有自己的数据库 。如果没有集中式数据库，我们可以根据需要为每个单独的微服务使用NoSQL、RDBMS或任何其他数据库，这是使微服务真正独立的原因之一 。
第三 ， 集成架构的问题
还是微服务架构解决的问题 。
3.1难以扩展
集成架构应用程序只能通过将整个应用程序的多个实例放在负载平衡器后面来进行水平扩展 。如果应用程序中的特定服务需要扩展，没有简单的选择 。我们需要完全扩展应用程序，这显然会造成不必要的资源浪费 。
相比之下，基于微服务的应用允许我们根据需要独立扩展单个服务 。上图中 ， 如果需要伸缩服务B，可以有10个实例，同时保留其他实例，可以根据需要随时更改 。
3.2交货时间长
统一架构在单个应用程序的任何部分/层所做的任何更改都需要构建和部署整个应用程序 。个别开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这影响了持续部署的效率 。
但是在微服务架构中，如果一百个微服务中只有一个需要改变，那么只会构建和部署改变后的微服务 ， 并不需要部署所有的 。我们甚至可以在短时间内部署多次 。
3.3应用程序复杂性
过去随着应用规模的增长(功能、功能等 。)，团队也会相应的扩大，应用很快就会变得复杂和纠结 。随着不同团队不断修改代码 ， 慢慢的维护模块化结构变得越来越困难，慢慢的就导致代码像意大利面一样交织在一起 。这不仅会影响代码质量，还会影响整个组织 。
在基于微服务的应用中，每个团队做一个单独的微服务，代码会有序很多 。
3.4没有明确的所有权
在集成应用中，看似独立的团队实际上并不独立 。他们同时在同一个代码库上工作，并且彼此非常依赖 。
在基于微服务的应用中，独立团队处理单个微服务 。一个团队会有一个完整的微服务 。工作的明确所有权清楚地控制了服务的一切，包括开发、部署和监控 。
3.5故障级联
如果设计不当，集成应用程序一部分的故障可能会导致整个系统崩溃 。
对于基于微服务的架构 ， 我们可以使用断路器来避免这种故障 。
3.6开发和运营之间的壁垒
开发团队通常进行开发和测试 。一旦部署，维护和支持的所有权将移交给操作和维护团队 。应用此时与开发团队无关，运维团队需要努力支持生产环境中的集成架构应用 。
在基于微服务的应用中，团队的组织被理解为“构建它并运行它”，开发团队在生产中继续拥有应用 。
3.7沉迷于某种技术/语言
使用集成架构意味着被实现的技术/语言所束缚 。如果需要更改技术/语言，整个应用程序都必须重写 。

推荐阅读


上一篇：明朝那些事儿一共几部 当年明月写的明朝那些事儿一共几部

下一篇：魅族虚化壁纸在哪里设置