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

　　这些底层资源的耦合和复杂性的变化，都值得上游的所有业务方予以关注。

　　由此可见，服务化可以让上述问题得到缓解。因为，它只需要一个团队去关注底层的复杂性。

　　如上图所示在升级之后，所有的业务侧通过 RPC 就像调用本地函数一样去获取远端的数据，只要传一个 UID 过去便能获取一个用户的实体。

　　具体这些数据是放在哪个分库中(是放在缓存中、MySQL 中、还是 MongoDB 中)，只需被服务层所关注。

　　而当底层需要升级的时候，所有的调用方，乃至所有的业务线都不会被牵动，我们只需对服务进行升级。可见，通过服务化，我们很好地解决了底层复杂性的耦合问题。

　　兄弟部分上线，为啥我们挂了?

　　在服务化之前，多个业务线会同时访问同一份数据，以前面的用户数据为例。

　　虽然我们的每个业务线都能够通过由 DAO 拼装的 SQL 语句去访问同一个数据层(当然也有些公司甚至都没有 DAO 层，而直接拼装 SQL 语句去访问数据库)，但是每个业务线上工程师的能力是不一样的。

　　较资深的工程师在拼装 SQL 的过程中，会考虑到索引以及优化等问题;但是一些经验欠佳的工程师在写下一行 DAO 代码的时候，可能不曾想到它所被转化的 SQL 语句。

　　还可能因为没有命中索引，而导致数据库的全盘扫描，进而出现 CPU 的利用率达到百分之百的问题。

　　过去，我们“搬家”的业务线曾写了一个非常低效的 SQL 语句并发布到了线上。

　　它直接导致了整个数据库实例的 CPU 利用率高达百分之百，进而影响到了“货的”和“优配”。

　　而由于“搬家”的订单量远小于“货的”和“优配”的订单量，那么“货的”一旦访问订单的时候，就会发现系统是访问不了的。

　　这就造成了：“搬家”的上线却导致“货的”“挂掉”了的局面。究其原因，正是因为该架构中 SQL 语句的质量没有得到很好的控制。

（编辑：西安站长网）

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