踩坑实践：如何消除微服务架构中的系统耦合

　　另外，除了 Join，还有各种子查询、自制定函数、视图、触发器，都可能出现耦合在一个实例的情况。因此，我们很难将这种结构拆成多个实例。

　　那么当业务越来越复杂、数据量越来越大、数据库里的数据表越来越多时，我们势必要消除数据库的耦合，通过微服务架构的改造来拆分出多个实例。

　　如图所示，最上方是原始的耦合，我们在下面抽象出来共性的数据，包括 user-service 和 db-user(一个单独的实例)。

　　对于个性化的数据，我们也要拆到个性化的库里。如果你要进一步拆分的话，我们还能对共性的数据以及个性的数据分别抽象成 Service。

　　如图所示，“搬家”、“货的”、“优配”都分别有自己的 Service，和各自的数据库，从而实现了将业务整体数据拆到了多个单实例中。

　　我们的拆分目标是：实现数据请求需要根据 UID 访问 RPC 接口，并基于 user-service 先拿到共性数据。

　　如果你只是抽象了数据库，那么需要用 UID 去拼装 SQL 以拿个性的数据;如果你也抽象了业务 Service，那么就通过 UID 自己做逻辑拼装，产生完整的 SQL 语句，去访问业务 Service 的接口，从而得到业务个性化的数据。

　　这是一个循序渐进的过程，我们耗时三个季度，对站点应用层的代码做了大量的修改工作。

　　完成之后，我们实现了：根据 DBA 新增的设备台数和新的实例，将数据拆出来并迁移过去。

　　由上可见，两层变三层的架构给我们带来了四点好处：

　　加强了复用性

　　屏蔽了复杂性

　　保证了 SQL 质量

　　确保了扩展性

　　而且调用方不再需要关注 JDBC、DAO 和缓存，只需传送 UID 便可。

　　微服务架构，存在什么问题?

　　众所周知，各种技术大会一般都只讲服务化和微服务的好处，几乎不会提及坑点。

　　而大家也不要盲目地评判诸如 Dubbo 等微服务框架的优劣，更不要以为引入了 RPC 框架，就实现了服务化。

　　我们通过亲自实践，在经历了改造、消除了耦合、演进了架构的过程中，也遇到过如下的问题：

　　微服务会带来系统复杂性的上升

　　即：原来由数据库单点做缓存，改造后会增加多个服务层。

　　层次依赖关系会变得非常复杂

　　即：原来是 Nginx/站点/数据库的模式，改造后引入了多个相互依赖的服务，包括数据库与缓存。

　　而且服务还可能会再次调用其他的服务，例如：我们的“同城”，它在业务上就像一个包含了各种帖子的论坛，一般由商业置顶推荐部分、付费部分、中间自然搜索部分、下面人工部分、以及右侧的个人中心所组成。

　　这些数据的展示，需要先访问商业服务进行搜索、获得搜索数据后，再推荐服务，以及调用个性化的数据，最后拼装成一个列表页面。

　　这些代码在各个业务线上都有重复。而如果商业的结构需要升级，则所有的业务线接口都予以跟进;如果推荐部分出现了 Bug，那么所有都要跟着修改。

　　因此我们把相同的公共部分抽象为通用列表的服务，由它来统一调用底层的商业服务、自然搜索服务、推进服务和个人服务。

　　随着业务逻辑的日趋复杂，我们的服务层次也会增多，而服务的抽象和相互之间的依赖关系也势必日渐复杂。

　　监控和运维部署也会变得复杂

　　例如：在一个站点上集群了三个节点的时候，我们在早期并没有专门地去做运维，而是首先 SSH 到第一台→wget 一个 war 包→解压→restart。然后同法炮制第二台、第三台。

　　那么当站点有十个以上时，运维就不能这么做了。因此从长远来看，我们需要开发自动化的运维脚本和运维平台。

　　那么在引入服务化之后，随着服务与集群数量的增加，运维部署与监控的工作量也势必会有所增加。

　　定位问题更麻烦

　　例如：当用户反馈登录缓慢时，负责 Web 登录的人员通过排查发现是列表服务的问题，就转给其列表服务人员。

　　列表服务的人员经查发现是调用不出用户中心了→则由负责用户中心的工程师进一步调查→他们上升到 DBA 那里→DBA 通过运维人员才发现是阿里云上的某个节点出了问题。

　　最终认定问题不大，只需重启或摘除掉该节点，以及修改网络配置便可恢复。可见这样的定位过程是极其复杂的。

　　综上所述，微服务也会给我们带来一些潜在问题，因此大家要事先考虑周全。

（编辑：辽源站长网）

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