微服务架构的两大解耦利器与最佳实践

这几年，微服务架构这个术语渐成热门词汇，但它不是一个全新架构，更不是一个包治百病的架构。那么，微服务架构究竟能够解决什么问题，又带来哪些痛点？

本文将与大家谈谈这个问题，以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践。

微服务架构解决的问题与带来的痛点

一

互联网高可用架构为什么要服务化？



上图是互联网典型的高可用架构，大部分公司如果没有使用微服务，正在使用这样的架构：

用户端是浏览器 browser，APP 客户端

后端入口是高可用的 nginx 集群，用于做反向代理

中间核心是高可用的 web-server 集群，研发工程师主要在这一层进行编码工作

后端存储是高可用的 db 集群，数据存储在这一层。更典型的公司，web-server 层是通过 DAO/ORM 等技术来访问数据库。

最初的架构都没有服务层，这样的架构会遇到怎样的痛点？对于没有使用微服务架构的公司来说，要不要升级到微服务架构呢？

58 同城和 58 到家的架构痛点

回答这个问题之前，先来看看您是否遇到和 58 同城及 58 到家类似的架构痛点：



图一，代码拷贝。A、B、C 业务线，如果没有微服务架构，可能要直接访问数据库里的数据来实现自己的业务需求。拿访问用户数据举例，用户中心包括所有公司必备的业务，比如登陆、注册、查找用户信息等。如某业务线需要访问用户信息，需要通过封装用户访问代码模块实现。如业务繁多，每个业务线都需要访问用户信息，潜在的会存在代码拷贝问题。

图二，底层复杂性扩散。随着流量的增长，需要加入缓存，对数据的访问模式和流程都会带来影响。从直接访问数据库，变到先访问缓存再访问数据库。这样的复杂性，所有的业务都需关注，代码都要重新做一遍。包括数据量增大后，要进行的水平线切分、分库、分表，存储引擎的变化等复杂性，要扩展到业务线。

图三，代码库耦合。58 同城遇到图一和图二问题，最初想到的方案并不是微服务，而是将相互拷贝的复杂性代码封装到一个代码库（DLL 或 jar 包），实现统一的相关功能，屏蔽复杂性。

拷贝代码的好处是代码独立演化，做改动互不影响。弊端是一旦用上库，业务就会耦合在一起，因共用jar包，一旦其中某个业务升级，其他的业务就可能受影响。

图四，数据库耦合。业务线不只访问 user 数据，还会结合自己的业务访问自己的数据：典型的情况是通过 join 数据表来实现各自业务线的一些业务逻辑。这样的话：

业务线 A 的 table-user 与 table-A 耦合在了一起；

业务线 B 的 table-user 与 table-B 耦合在了一起；

业务线 C 的 table-user 与 table-C 耦合在了一起；

结果就是：table-user，table-A，table-B，table-C都耦合在了一起。随着数据量的越来越大，业务线 ABC 数据库无法进行垂直拆分，必须使用一个大库（疯了，一个大库 300 多个业务表 =_=）。

图五，SQL 质量得不到保证，业务之间互相影响。由业务方拼装的 SQL 语句调用方式，通过 ORM（对象关系映射）的方法生成 SQL 语句数据库，这个库是共用的，会影响所有的业务线。一旦某业务有慢 SQL 出现，其他业务就会受影响。

回到要不要做微服务升级的问题，如果大家所负责的系统、模块或公司也存在以上的这些问题，建议考虑做服务化，在中间加一个服务层，所有调用不允许直接连接底层库。服务化还有一个很重要的特点就是数据库私有化，任何人不能跨越服务程序，干预数据库。想调用要通过接口来实现，当数据库性能变差，直接加一台机.....

点击查看更多：《微服务架构的两大解耦利器与最佳实践》