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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　另外，我们也需要遵从 SQL、Java 等方面的编程规范。我在负责 DBA 部门的时候，就曾要求：无论什么规范，都必须限定在十条以内，以合适一张 A4 纸单面打印出来。

　　在做了服务化之后，服务层应能够向上游业务提供一些相对比较通用的 RPC 访问，我们籍此可以通过服务层来控制 SQL 的质量。

　　这里同样以用户数据的“增、删、查、改”为例，在用户侧访问时，如果你传来用户名/密码，我就回传 UID;如果你传来一个 UID，我就给你一个用户的实例。

　　可见，这些接口都是非常有限且通用的。它们对于数据库的访问，都被控制在 Service 上，而非用户层面。所以我总结出来服务化具有如下原则：

　　数据库私有

　　任何上游不得绕过 Service 去访问底层数据库。业务层只能调用接口，即 SQL 由服务所决定，这一点很重要。

　　对上游提供有限且通用的接口

　　许多公司虽然做了服务化，但是服务层仍然有许多个性化的、与业务紧密相关的接口，这就没有达到服务化的目的。

　　例如：我们曾经在 user-service 里，有着大量与“搬家”、“货的”、“优配”相关的业务代码，一旦上游出现新的需求，他就提交给服务层去修改。

　　这样的话，user-service 实际上实现的是各种个性化的需求，由于这些接口的复用性低，因此不但会导致其代码的混乱，还会造成研发的瓶颈。可见，服务化只应该提供有限的通用接口。

　　服务侧要保证无限的性能

　　我们通过水平扩展、加缓存、分表等方式去解决各种并发量、吞吐量、和数据量的问题，从而保证了上游侧不必关心各种操作的实现细节。这就是服务维护者对外的一种服务承诺。

　　业务一旦出了问题只会影响到自己;如果服务出现了故障，那么就会有深远的影响，甚至会导致用户无法登录。

　　可见，诸如用户 Service、订单 Service、支付 Service、商家 Service，都必须具有良好的稳定性。

　　我们曾经在“同城”做过的一个实践是：将公司最基础的 Service 放置在架构部，由资深的工程师去做维护。

（编辑：辽源站长网）

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