Spring单块架构没落，微服务兴起，想问下，感觉微服务只是将原来一个系统的才分为小的模块，至于怎么小，就是各个系统拆分设计的艺术。
小弟有个问题想问下，就是有一个小的模块，采用微服务，如果服务数多了，假如100个，每个服务默认使用的连接池配置是初始化10个，最大100个连接，如果超过默认数据库连接时，怎么办？又或者采用什么方式来避免数据库连接资源的成倍增长？
+
单块架构没落，微服务兴起，想问下，感觉微服务只是将原来一个系统的才分为小的模块，至于怎么小，就是各个系统拆分设计的艺术。
小弟有个问题想问下，就是有一个小的模块，采用微服务，如果服务数多了，假如100个，每个服务默认使用的连接池配置是初始化10个，最大100个连接，如果超过默认数据库连接时，怎么办？又或者采用什么方式来避免数据库连接资源的成倍增长？
分两部分吧，程序上的优化和数据库上的优化。
程序上，优化代码，尽量减少数据库的读写，逻辑尽量不要放到数据库层，尽早释放连接，能重用时尽量避免重新获取新的连接等等。
数据库上，优化数据库配置，采用一主多从、多主多从、分数据库服务器等方法，通过增加数据库服务器分担单台的压力。
如果不断成倍增长，可能要考虑重构现有逻辑，将不同的数据分别存储到不同的数据库服务器上。
这个在设计之初就要考虑到，你所有服务的最大连接数之和不能超过数据库的连接数上限
如果这个连接数很大，数据库服务器的性能不够用的情况下，就需要将数据库做成主从，做读写分离等分散压力
异步，队列
线程池数量已经满了，如果并发已经确定超过限制，没办法的了，
限制分流，排队
数据服务由单独的微服务提供，很多微服务不要直接访问数据库，而是访问提供数据的微服务。
两个方案吧
1、业务服务 + 基础服务(mysql、redis 实现通用的增删改查接口)
2、单元化