随着业务越拆越小，而且各个应用又是独立部署和维护的，这样的架构存在以下问题：
1，数据库连接数的问题，如果各个应用都连接现有数据库，当使用集群和并发访问量大的情形下，就会导致数据库连接数超过限制。当然，如果各个应用都有自己的数据库，则不存在这个问题。
2，代码复用的问题，有些基础信息在各个应用中都存在，比如用户信息，这样就造成代码的重复和变成难以维护。
服务化
服务化就是把每个应用都需要执行的业务操作，比如员工信息和客户信息，提供出来，然后独立部署和维护，由这些可复用的业务连接数据库，提供共用业务服务(api接口)，而应用系统只需要管理用户界面，通过远程服务调用完成具体业务操作。架构如下图：
总结：
1，服务化解决了业务拆分后的代码复用问题和数据库连接问题，同时也衍生出来一个问题：原来业务之间的调用是单机内部的方法调用，现在变成了远程的服务调用，即通常的RPC，如果使用了分布式服务，还要考虑引入服务框架中间件。
2，如果在服务实现了分布式的情形下，单纯解决服务路由的问题，可以在服务层前面使用负载均衡服务器来解决。
3，关于微服务的架构，还需要后面的理论加实践中慢慢总结。