[云原生]微服务架构是什么?

Posted 2022-07-11 Philosophy7

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[云原生]微服务架构是什么?相关的知识，希望对你有一定的参考价值。

✅作者简介：大家好,我是Philosophy7？让我们一起共同进步吧！🏆 📃个人主页：Philosophy7的csdn博客
🔥系列专栏：数据结构与算法
👑哲学语录: 承认自己的无知，乃是开启智慧的大门
💖如果觉得博主的文章还不错的话，请点赞👍+收藏⭐️+留言📝支持一下博>主哦🤞

微服务架构

一、为什么需要微服务架构

新事物的产生必将会与旧事物发送冲突，而一个新事物的生命力，就是看有无发展空间，那么微服务架构也不例外。随着互联网技术的发展，传统的应用架构已经无法满足实际需求，微服务架构就随之产生。那么传统应用架构到底有什么问题呢？又如何解决呢？

①传统单体应用架构的问题

通常我们使用的传统单体应用架构都是模块化的设计，程序在编写完之后会被打包并部署称一个具体的应用，而应用的格式依赖于相应的应用语言和框架。例如: 某电商项目，Web工程会被打成WAR包的形式部署在Web服务器上，而普通的Java程序则被打成一个Jar包的形式包含在WAR中。

如图，这种是我们常见的开发风格，这样做的好处利于开发和调试，并且容易部署。在客户量不多的情况下，这种架构方式(单体应用架构)完全满足需求，但随着用户量的增加，一台服务器就满足不了，此时我们就会考虑系统的水平扩展，通常我们的解决方案就是增加服务器的数量，并将打包好的应用拷贝到不同的服务器(例如:Tomcat),通过负载均衡器（Apache、nginx）轻松实现水平扩展。

这种架构的存在的问题如下：

应用复杂度增加，更新、维护困难
- 简单的应用随着多次更新、维护会变的庞大，应用将会变的复杂，开发团队面临多种问题，其中最主要的问题就是应用太复杂，以至于单个开发者很难进行二次开发或维护
易造成系统资源浪费
- 虽然使用负载均衡的方式跨域对项目中的服务容量进行水平扩展，但由于单体应用架构的代码中只有一个包含所有功能的WAR包，所以在对服务容量扩容的同时，只能选中重复地部署这个WAR包来扩展服务能力，而不仅仅是扩展了所需服务。
影响开发效率
- 当一个应用越大时，启动的速度会大大降低。在开发和调试中，如果有大部分的时间花费在启动上，那么会大大影响开发效率。
应用可靠性低
- 单体应用架构的可靠性较低，当某个模块产生BUG时，很可能导致整个进程崩溃，从而影响到整个应用。
不利于技术的更新
- 传统单体应用架构一旦选定了某些技术，后期的开发和扩展将在这些技术的基础上进行实现。如果需要更改某种技术，那么则很有可能会将整个应用重新开发。

②解决传统应用架构的问题

针对传统单体架构的问题，大部分企业通过SOA(Service-Oritend Architecture) 面向服务的架构解决上述问题。SOA的思路就是将应用相近的功能聚合到一起，以服务的形式提供出去，因此SOA架构的应用跨域简单理解为一批服务的组合。

整体的一个项目拆分成若干个子项目，不同的开发团队负责不同的子项目，提高开发效率
将模块拆分，使用接口通信，降低模块间的耦合度
使客户或服务消费者免于服务实现的改变所带来的影响

虽然使用SOA解决了传统单体架构中的问题，但多数情况下，SOA中相互独立的服务仍会被部署到同一个Tomcat实例下，和单体应用架构相似，随着业务功能的增多，SOA的服务也会变的复杂。透过现象看本质，单体架构的问题仍没有得到解决。

针对这种问题，微服务架构的架构思想也随之产生，也就是将应用分解为小的、互相连接的微服务。

二、微服务架构是什么?

微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能进行更加细粒度的拆分，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，跨域独立承担对外服务的职责，通过这种思想开发的软件服务实体就是微服务，而围绕着微服务思想构建的一系列体系结构(开发、测试、部署等)我们将它称之为微服务架构

①微服务架构的优点

复杂度可控
- 更细粒度的应用拆分，不会随着时间的演变而变的复杂，每一个服务只专注于一个小功能。
可独立部署
- 由于微服务具备独立的运行进程，所以每个微服务都可以独立部署。
技术选型灵活
- 微服务架构下，技术的选型是多样化的。每个团队根据不同的需求选择最适合的技术。
易于容错
- 当某一个组件发送故障时，只会影响在一个细小的服务中，通过重试即可重新上线使用。
易于扩展
- 单个服务应用也可以实现水平扩展，这种扩展可以将整个应用完整的复杂到不同的节点中实现。
功能稳定
- 每个微服务都有自己的业务逻辑和适配器，并且只完成某个特定的功能，例如商品服务只管理商品等。

②微服务架构的不足

开发者必须处理创建分布式系统的复杂性
- 开发工具是面向构建传统的单体应用程序的，不为开发分布式应用程序提供全面功能上的支持(典型开发工具：Eclipse)
测试更加困难。在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务之间需要通过接口进行交互。
实现跨多个服务用例，需要团队之间进行仔细的协调。
部署的复杂性将会大大增加，这也就意味着开发、测试、运维人员需要账务更扎实的技术
增加内存消耗，微服务架构用多个服务实例取代了1个单体应用程序实例，若每个服务都运行在增加的JVM中，那么有多少个服务实例，就会有多少个实例在运行时的内存开销。

③微服务架构和SOA的区别

微服务架构	SOA
一个系统被拆分成多个服务，细粒度	服务由多个子系统组成，粗粒度
团队级，自下向上开展实施	企业级，自上向下开展实施
无集中式总线，松散的服务架构	企业服务总线，集中式的服务架构
集成方式鸡蛋	集成方式复杂
服务能够独立部署	服务相互依赖，无法独立部署