为什么要做服务化拆分

一体化架构的痛点

所谓“一体化架构”就是说所有的功能模块，都被打包到一个web工程中，然后部署到应用服务器上。这种架构的优点如下：

• 开发简单直接，代码和项目集中式管理
• 只需要维护一个工程，节省维护系统运行的人力成本
• 排查问题的时候，只需要排查这个应用进程就可以了，目标性强

但是随着系统规模变大，以缺陷会慢慢体现处理，比如：

• 在技术层面上，数据库连接数可能成为系统的瓶颈
  • 数据库连接是一种比较重的资源，不仅连接过程比较耗时，而且连接MySQL的客户端数量有限制，最多可以设置为16384（在实际的项目中，可以依据实际业务来调整）。
  • 这个数字看着很大，但是因为系统是一体化架构，在部署结构上没有分层，应用服务器直接连接数据库，那么当前端请求量增加，部署的应用服务器扩容，数据库的连接数也会大增。
  • 举个例子，有个系统，其数据库最大连接数设置为8000，应用服务器部署在虚拟机上，数量大概是50个，每个服务器会和数据库建立30个连接，但是数据库的连接数，却远远大于30 * 50 = 1500。
  • 因为你不仅要支撑来自客户端的外网流量，还要部署单独的应用服务器，支撑来自其他部门的内网调用，也要部署队列处理器，处理来自消息队列的消息。
  • 所以，一旦遇到一些大型的运营推广活动，服务器就要扩容，数据库连接数也会随之增加，就会处于最大连接数的边缘。这随时会影响服务的文档
• 一体化架构增加了研发的成本，抑制了研发效率的提升。
  • 当小团队共同维护一套代码，和一个系统时，在配合时就会出现问题。
  • 由于代码部署在一起，每个人都向同一个代码库提交代码，代码冲突无法避免；同时，功能之间耦合严重，可能你只是更改了很小的逻辑，却导致其它功能不可用，从而在测试时需要对整体功能回归，延长了交付时间。
  • 一体化架构，就像是一个大的蜘蛛网，不同功能模块，错综复杂地交织在一起，方法之间调用关系非常的复杂，导致你修复了一个 Bug，可能会引起另外多个 Bug，整体的维护成本非常高。同时，数据库较弱的扩展性，也限制了服务的扩展能力
• 一体化架构对于系统的运维也会有很大的影响
  • 在项目初期，你的代码可能只有几千行，构建一次只需要一分钟，那么你可以很敏捷灵活地频繁上线变更修复问题。但是当你的系统扩充到几十万行，甚至上百万行代码的时候，一次构建的过程，包括编译、单元测试、打包和上传到正式环境，花费的时间可能达到十几分钟，并且，任何小的修改，都需要构建整个项目，上线变更的过程非常不灵活。

而我说的这些问题，都可以通过微服务化拆分来解决。

如何使用微服务化解决这些痛点

比如说有一个系统，采用的是一体化架构，数据库也做了垂直拆分，分出了用户库、内容库和互动库，并且已经将工程拆分了业务池，拆分成了用户池、内容池和互动池。

问题：当前端的请求量越来越大时，无论哪个业务池子，用户模块都是请求量最大的模块，用户库也是请求量最大的数据库。因为无论是内容还是互动，都会查询用户库获取用户数据。也就是说，即使我们做了业务池的拆分，但实际上，每一个业务池子都需要连接用户库，并且请求量很大，这就造成了用户库的连接数比其他都要多一些，容易成为系统的瓶颈。

那我们应该怎么解决这个问题呢？

• 可以把用户相关的逻辑，部署成一个单独的服务，其他无论是用户池、内容池还是互动池，都连接这个服务来获取和更改用户信息。也就是说，只有这个服务可以连接用户库，其他的业务池都不直连用户库获取数据。
• 由于这个服务只处理和用户相关的逻辑，所以，不需要部署太多的例子就可以承担流量，这样就可以有效的控制用户库的连接数，提升了系统的可扩展性。那么这样一来，我们也可以将内容和东湖相关的逻辑，都处理出来，形成内容服务和互动服务。这样，我们就通过按照业务做横向拆分的方式，解决了数据库层面的扩展性问题。

微服务化后，系统架构要如何改造

在这个架构中，我们将订单、用户、商品相关的逻辑，抽取成服务独立的部署，原本的web工程和队列处理程序，将不再直接依赖缓存和数据库，而是通过调用服务接口，查询存储中的信息。

也就是说做了服务拆分。但是具体应该怎样拆分呢？比如：

• 服务拆分时要遵循哪些原则？
• 服务的边界如何确定？服务的粒度是怎么样的呢？
• 在服务化之后，会遇到哪些问题呢？我们又将如何来解决？

微服务拆分的原则

标签：架构,服务化,数据库,连接数,并发,拆分,服务,用户库
来源： https://blog.csdn.net/zhizhengguan/article/details/121246013