浓缩精华的架构演进过程，我连看了六遍！

②对于数据库来说，每个数据库能够承受的最大连接数和连接池是有上限的。为了提高数据访问效率，会根据业务需求对数据库进行分割，让不同的业务访问不同的数据库。当然，也可以将相同业务的不同数据放到不同的库中存储。

如果将这些数据库资源分别放到不同的数据库服务器中，就是分布式数据库设计了。

由于数据存储在不同的表/库中，甚至在不同的服务器上面，在进行数据库操作的时候会增加代码的复杂度。此时可以加入数据库中间件来消除这些差异。

图 8：分布式数据库与分表分库

架构如图 8 所示，将数据拆分以后分别放在表 1 和表 2 中，两张表所在的数据库服务器也各不相同，库与库之间还需要考虑数据同步的问题。

由于数据的分散部署，要从业务应用获取数据就需要依靠数据库中间件帮忙。

数据库的分表分库以及分布式设计，会带来性能的提升，同时也增大了数据库管理和访问的难度。原来只用访问一张表和一个库，现在需要跨越多张表和多个库。

从软件编程的角度来看，有一些数据库中间件提供了最佳实践，例如 MyCat 和 Sharding JDBC。

此外，从数据库服务器管理的角度来看，需要监控服务器的可用性。从数据治理的角度来看，需要考虑数据扩容和数据治理的问题。

业务拆分

当解决大数据量存储问题以后，系统就能够存储更多的数据，这意味着能够处理更多的业务。

业务量的增加，访问数的上升，是任何一个软件系统在任何时期都要面临的严峻考验。

通过前面几个阶段的学习，我们知道系统提升基本依靠空间换取时间，使用更多的资源和空间处理更多的用户请求。

随着业务的复杂度越来越高，以及高并发的来临，一些大厂开始将业务系统进行切分，分开部署。

此时的架构图如图 9 所示：

图 9：业务拆分

如果说前面的服务器集群模式是将同一个应用复制到不同的服务器上，那么业务拆分就是将一个应用拆成多个部署到不同的服务器中。

此外，还可以对核心应用进行水平扩展，将其部署到多台服务器上。应用虽然做了拆分，但应用之间仍旧有关联，存在应用之间的调用、通信和协调问题。

由此也会引入队列、服务注册发现、消息中心等中间件，它们可以协助系统管理分布到不同服务器、网络节点上的应用。

业务拆分以后会形成一个个应用服务，既有基于业务的服务，例如商品服务、订单服务，也有基础服务，例如消息推送和权限验证。

这些应用服务连同数据库服务器分布在不同的容器、服务器、网络节点中，对它们的通信、协调、管理和监控都是我们需要解决的问题。

分布式与微服务

近几年，微服务是比较火的架构方式，它将业务应用进行更加精细化的切割，使之成为更加小的业务模块。

做到模块的高内聚低耦合，每个模块可以独立存在，由独立的团队维护。每个模块内部可以采取特有的技术，而不用关心其他模块的技术实现。

模块通过容器的部署运行，模块之间通过接口和协议进行调用。任何一个模块都可以将自己公开给其他的模块调用。

同时可以将热点模块进行水平扩展，增强系统的性能。当其中某一个模块出现问题时，又可以由其他相同的模块代替其工作，增强了可用性。

大致总结下来，微服务拥有以下特点，业务精细化拆分、自治性、技术异构性、高性能、高可用。

它像极了分布式架构，下面来看看它们的区别，如图 10 所示：

图 10：分布式与微服务的区别

从概念上理解，它们都做了“拆”的动作，但在下面这几个方面存在区别：

①拆分目的不同：分布式设计是为了解决单体应用资源有限的问题，在一个服务器上无法支撑更高的用户访问，因此将一个应用拆解成不同的部分，然后将其部署到不同服务器上，从而分担高并发的压力。

微服务是对服务组件进行精细化，目的是更好地解耦，让服务之间通过组合完成高性能、高可用、可伸缩、可扩展。

②拆分方式不同：分布式服务架构将系统按照业务和技术分类进行拆分，目的是让拆分的服务负载原来单一服务的业务。

微服务则是在分布式的基础上进行更细的拆分，它将服务拆成更小的模块，更加专业化，分工更加精细，并且每个小模块都可以独立运行。

③部署方式不同：分布式将服务拆分以后，通常会部署到不同的服务器上。

而微服务也可以将不同的服务模块放到不同的服务器上，同时它也可以在一个服务器上部署多个微服务，或者同一个微服务的多个备份，并且多使用容器的方式部署。

虽然分布式与微服务有以上区别，但从实践的角度来看，它们都是基于分布式架构的思想构建的。

微服务是分布式的进化版本，也是分布式的子集。它同样会遇到服务拆分、服务通信、协同、管理调度等问题。

总结

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!