为何要使用微服务架构？

时间 2019-11-15

原文原文链接

微服务架构已经流行了很长时间，可是想要回答为何要使用微服务架构的问题，首先应该了解一体化架构。git

什么是一体化架构？

一体化架构顾名思义，将应用各层打成一个包来部署。为了让代码正常工做，一体化应用的全部组件缺一不可。github

以典型的3层传统web应用为例，该应用由用户界面、数据库、服务器端应用组成。这里的服务器端应用被称为monolith（一体化），包含表现、业务层、数据层。全部代码都存在于同一个代码库中。为了让代码工做起来，它被部署成为一个单元。任何一个小的改动变化，都须要从新构建和部署整个应用。web

微服务架构是一种架构风格，整个应用被划分并设计为以业务域为模型的松散耦合的独立服务。微服务中的“微”很是具备欺骗性，事实上它没有规定服务的规模有多小或多大。数据库

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

在基于微服务的架构中，每一个组件或服务都有本身的数据库。没有集中式数据库，咱们能够根据须要为每一个单独的微服务使用NoSQL、RDBMS或任何其余数据库，这也是让微服务真正独立的缘由之一。服务器

或者说是微服务架构所解决的问题。微信

一体化架构应用只能经过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。若是应用中的特定服务须要扩展，则没有简单的选项。咱们须要完整地扩展应用程序，这显然会形成没必要要的资源浪费。架构

相比之下，基于微服务的应用程序容许咱们根据须要独立扩展单个服务。在上图中，若是须要缩放服务B，则能够有10个实例，同时保持其余实例，并能够根据须要随时更改。负载均衡

一体化架构在单个应用的任何部分/层中进行的任何更改都须要构建和部署整个应用程序。我的开发人员还须要下载整个应用程序代码来修复和测试，而不只仅是受影响的模块，这就影响到了持续部署的效率。框架

而在微服务架构中，若是仅在一百个微服务中的一个中须要改变，则仅构建和部署改变的微服务，没有必要部署一切。咱们甚至能够在短期内屡次部署。

过去，随着应用规模的增加（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一块儿。随着不一样的团队不断修改代码，维护模块化结构慢慢变得愈来愈困难，并慢慢致使像意大利面同样交织的代码。这不只会影响代码质量，还会影响整个组织。

在基于微服务的应用中，每一个团队都在单独的微服务上工做，代码会有序不少。

在一体化应用中，看起来独立的团队实际上并非独立的。它们同时在相同的代码库上工做，严重依赖于彼此。

在基于微服务的应用中，独立团队处理单独的微服务。一个团队将拥有一个完整的微服务。工做的明确全部权明确控制服务的一切，包括开发、部署和监控。

若是没有正确设计，一体化交媾应用的一部分失败可能会级联并致使整个系统崩溃。

在基于微服务的架构的状况下，咱们可使用断路器来避免这种故障。

开发团队一般会进行开发、测试，一旦部署，就会将维护和支持的全部权交给运维团队，应用此时与开发团队无关了，而运维团队须要努力在生产环境中支持一体化架构应用。

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

使用一体化架构，意味着被某种已实现的技术/语言锁定。若是须要更改技术/语言，则必须重写整个应用程序。

使用微服务，每一个服务能够根据需求和业务以不一样的技术或语言实现。任何改变服务技术/语言的决定都只须要重写该特定服务，由于全部微服务都是相互独立的。

几年前，咱们尚未适当的工具和技术来支持微服务。但自从Docker容器和云基础设施（特别是PaaS）向大众提供服务以来，微服务正在大规模采用，由于它们提供了咱们所需的“自由”，而无需进行传统的配置程序。

简单来讲，使用微服务架构会得到如下好处：

当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通讯问题时，开始考虑采用Service Mesh微服务架构做为服务与服务直接通讯的透明化管理框架，以插件式的方式实现各类业务所需的高级管理功能。

而开源PaaS Rainbond提供了开箱即用的Service Mesh微服务架构，部署在Rainbond上的应用原生便是Service Mesh微服务架构应用。