微服务 - 单体项目与分布式项目两种架构设计思想？

Question

网上有资料说在大型的数据中心里，数据库就只有存储的功能，事务的功能会被疯狂削减。

因为没有微服务相关经验，所以不太理解这句话，所以希望有大佬可以讲一下将单体架构与微服务架构的设计思想

Answer 1

事务的功能削减

因为在微服务系统中，数据库往往不是一个，因为使用同一个数据库就容易出现数据库事务死锁。

假设用户下单需要经过三个系统：用户系统、订单系统、钱包系统，三个系统共用一个数据库。假设有新手偷懒，在钱包系统中直接查询了订单数据也使用了事务。
于是在用户下单时候，订单系统为了保障库存的扣除启用了订单事务，经过钱包系统时候，扣除余额也 使用了事务。两个系统的事务就造成了死锁，接口直接崩溃。

所以从一开始应该从根本上直接避免这个情况，而且分库优点也有很多。

1. 稳定；多个数据库服务器，防止个体服务造成的数据库崩溃引起的大范围雪崩
2. 性能；数据分为多个数据库，可以根据服务的重要性分到不同的云服务器，自然获得更好的性能
3. 安全；各自项目使用各自的数据库，自然不会出现数据安全问题

单体应用与分布式项目的设计思想。

单体应用优缺点

单体应用最出色的应该就是Java的那套了。优点很多：

1. 代码复用方便
2. 运维系统复杂度低
3. 无服务间的网络开销即性能更好
   缺点一样多：
4. 屎山越堆越高
5. 代码越多，复杂性越高，开发人员要求越高

微服务项目优缺点

优点：

1. 由于单个服务的代码量小，所以单个服务的复杂度很低，开发容易，代码优化（重构）方便。
2. 对普通开发人员要求低，对核心开发要求高。
3. 扩展容易、功能复用性高。
   缺点：
4. 性能一定会削减，毕竟有网络开销
5. 系统维护复杂度高，有Kubernetes后容易了很多
6. 系统Debug难度高，途径系统太多，没有好的监控系统不好排查问题。需要加入链路追踪增强
7. 系统开发难度对核心开发人员要求高，需要有高级开发带领开发需求，跨服务建设。

Answer 2

首先，让我们了解一下单体架构和微服务架构的基本概念：

1. 单体架构（Monolithic Architecture）：这种架构将所有功能都打包成一个单一的、庞大的应用程序。所有业务逻辑、数据访问和事务处理都在一个单一的代码库中实现。因此，单体架构通常在应用程序的部署和维护方面较为简单，因为所有的功能都是相互依赖的。
2. 微服务架构（Microservices Architecture）：微服务架构将一个大型应用程序拆分成多个小型、独立的服务，每个服务都运行在自己的进程中，并使用轻量级通信协议（如HTTP）进行通信。每个服务都只关注自己的核心功能，并通过定义良好的接口与其他服务进行交互。这种架构使得每个服务都可以使用不同的技术栈，提高了系统的可扩展性和灵活性。

在大型数据中心中，数据库通常被用作一个集中的数据存储和服务。由于数据库在微服务架构中被用作服务的一部分，因此它也需要与其他服务进行交互。在某些情况下，数据库的事务功能可能会受到影响，但这并不意味着事务功能会被削减或忽略。实际上，事务管理在微服务架构中仍然非常重要，因为多个服务之间的数据一致性是分布式系统中的一个关键问题。

在微服务架构中，由于系统被拆分成多个独立的服务，每个服务都有自己的数据库。因此，事务管理变得更加复杂，因为需要协调多个服务之间的数据操作。一种常见的方法是采用分布式事务，例如使用两阶段提交（2PC）或多阶段提交（多阶段提交）协议来确保数据的一致性。此外，还可以使用补偿事务（Compensating Transactions）来处理某个服务的事务失败对其他事务的影响。

总之，单体架构和微服务架构有各自的设计思想和优点。在选择适合您项目的架构时，应该根据具体的需求和约束进行权衡。对于大型数据中心而言，合理的设计和配置这些架构的关键在于理解它们的基本概念和事务管理的复杂性，并根据实际情况做出最佳决策