微服务共用数据库、独立数据库的区别和利弊

孙小亘

已于 2024-08-31 15:34:56 修改

阅读量132

点赞数

分类专栏： # 微服务文章标签：微服务数据库运维云原生架构

于 2024-08-27 11:48:24 首次发布

原文链接：https://www.baidu.com/link?url=UgQv669qImBfzI5o5PJNcbwsvXvqcQtDrEv9X8CpyDAZuuISWXKqlrkY00Aqa4QGU5qCxfp54goTv__YYYkCQ4wHtfQYIghA0xrLHtWAfZEBeixsdPE2vpW97ufs4v5ZZc6nohfnz53SnzcBAiZaaAnZC4tY_L6EBqdku2EZws2juyMmlgMgEM6yCjIcWANJ1_-YY-n-6cr3lPHsuAZ0Cq&wd=&eqid=

版权

微服务专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、微服务共用数据库、独立数据库的区别利弊

微服务架构下，几十个微服务都使用同一个mysql数据库，与各个微服务都使用自己的库的区别利弊。

1、数据一致性

使用同一个数据库的数据一致性更高，所有微服务共用一个库，可以避免不同服务之间由于数据不同步而产生一致性问题。使用各自的数据库会出现数据一致性问题，数据分散在不同的库中，可能会出现数据不一致的问题。

2、数据管理

使用同一个数据库的数据管理更方便，一个库管理起来比多个库更方便，例如备份、恢复、扩容等操作。使用各自的数据库会增加数据管理的复杂性，多个库需要进行备份、恢复、扩容等管理，工作量和成本更高。

3、数据库性能

使用同一个数据库的弊端在于数据库性能瓶颈：当多个微服务同时访问同一个库时，可能会产生数据库性能瓶颈导致整个系统的性能下降。使用各自的数据库会解决数据库性能瓶颈问题，每个微服务可以独立承担自己的数据库访问压力，避免了多个微服务同时访问同一个库导致的性能瓶颈问题。

4、数据安全性

使用同一个数据库会增加数据安全风险，多个微服务共用一个库时，如果其中一个服务遭受攻击或者出现故障，可能会对整个库造成影响，增加了系统的风险。使用各自的数据库能使数据安全性更高，每个微服务使用自己的库，可以隔离各个服务之间的数据，降低因为某个服务遭受攻击而影响整个系统的风险。

二、微服务架构

1、微服务架构介绍

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

2、出现和发展

微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。

Martin Fowler是国际知名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家。在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界拔尖的专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和——集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍：《企业应用架构模式》、《UML精粹》和《重构》等。

3、传统开发模式和微服务的区别

先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

优点：

开发简单，集中式管理基本不会重复开发功能都在本地，没有分布式的管理和调用消耗。

缺点：

效率低：开发都在同一个项目改代码，相互等待，冲突不断；

维护难：代码功功能耦合在一起，新人不知道何从下手；

不灵活：构建时间长，任何小修改都要重构整个项目，耗时；

稳定性差：一个微小的问题，都可能导致整个应用挂掉；

扩展性不够：无法满足高并发下的业务需求。

常见的系统架构遵循的三个标准和业务驱动力：

提高敏捷性：及时响应业务需求，促进企业发展；

提升用户体验：提升用户体验，减少用户流失；

降低成本：降低增加产品、客户或业务方案的成本。

关于微服务的一个形象表达：

X轴：运行多个负载均衡器之后的运行实例；

Y轴：将应用进一步分解为微服务（分库）；

Z轴：大数据量时，将服务分区（分表）。

4、微服务的具体特征

官方的定义：

一些列的独立的服务共同组成系统单独部署，跑在自己的进程中每个服务为独立的业务开发分布式管理非常强调隔离性。

大概的标准：

分布式服务组成的系统按照业务，而不是技术来划分组织做有生命的产品而不是项目强服务个体和弱通信（ Smart endpoints and dumb pipes ）自动化运维（ DevOps ）高度容错性快速演化和迭代。

5、微服务的优点

它解决了复杂性的问题，它会将一种怪异的整体应用程序分解成一组服务。虽然功能总量不变，但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动的API的形式定义了一个明确的边界；Microservice架构模式实现了一个模块化水平。这种架构使每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的技术，只要该服务符合API合同。当然，大多数组织都希望避免完全无政府状态并限制技术选择，然而，这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时，他们可以选择使用当前的技术。此外，由于服务相对较小，因此使用当前技术重写旧服务变得可行。Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。这些变化可以在测试后尽快部署。例如，UI团队可以执行A | B测试，并快速迭代UI更改。Microservice架构模式使连续部署成为可能。Microservice架构模式使每个服务都可以独立调整。您可以仅部署满足其容量和可用性限制的每个服务的实例数。此外，您可以使用最符合服务资源要求的硬件。

6、微服务的缺点

一个缺点是名称本身，术语microservice过度强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署。微服务器的另一个主要缺点是分布式系统而产生的复杂性。开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务交易是相当普遍的。但是，在基于微服务器的应用程序中，您需要更新不同服务所拥有的多个数据库。使用分布式事务通常不是一个选择，而不仅仅是因为CAP定理。测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样做的复杂性。Microservice架构模式的另一个主要挑战是实现跨越多个服务的更改。例如，我们假设您正在实施一个需要更改服务A，B和C的故事，其中A取决于B和B取决于C。在单片应用程序中，您可以简单地更改相应的模块，整合更改，并一次性部署。部署基于微服务的应用程序也更复杂。单一应用程序简单地部署在传统负载平衡器后面的一组相同的服务器上。每个应用程序实例都配置有基础架构服务（如数据库和消息代理）的位置（主机和端口）。相比之下，微服务应用通常由大量服务组成。