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

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

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

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

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

　　数据库私有

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

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

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

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

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

　　服务侧要保证无限的性能

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

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

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

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

　　数据库拆分真的容易?

　　在最早期，由于 58 速运的数据量较小，我们只用一个库将所有表格包含其中。

　　这些表中既有如用户表这样的公共表格，也有一些业务个性化的表格，例如与“搬家”相关的一些用户信息。

　　公共表以 UID 为 Key 放置用户公布的属性;个性化表同样以 UID 为 Key，包括“搬家”用户个性化属性。那么，“搬家”的某些业务场景可能会同时提取公共的和个性化的数据。

　　由于只有一个库、一个实例，我们通过简单代码直接根据相同的 UID、运用 Join 去操作两张表，便可取出所有需要的数据。即使用到对于 UID 的索引，也不会有多次的交互，或出现性能的问题。

　　当然，这些都是基于两张表必须在同一个实例中的前提条件。同理，我们的“货的”、“优配”也是这么各自构建的。

（编辑：西安站长网）

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