架构师不会架构选型，能行吗？( 二 )

分库分表是小 Case ，准备分库分表的阶段，才是重点：也就是数据同步。
数据同步

本文插图
推荐：Canal 。
国内使用 MySQL 的公司居多，但 PostgreSQL 凭借其优异的性能，使用率逐渐攀升。
不管什么数据库，实时数据同步工具，都是把自己模拟成一个从库，进行数据拉取和解析。
具体来说， MySQL 是通过 Binlog 进行同步;PostgreSQL 使用 Wal 日志进行同步。
对 MySQL 来说， Canal 是国内用的最多的方案;类似的 Databus 也是比较好用的工具。
现在， Canal、Maxwell 等工具，都支持将要同步的数据写入到 MQ 中，进行后续处理，方便了很多。
对于 ETL(抽取、清洗、转换)来说，基本上都是 Source、Task、Sink 路线，与前面的功能对应。 Gobblin、Datax、Logstash、Sqoop 等，都是这样的工具。
它们的主要工作，就是怎么方便的定义配置文件，编写各种各样的数据源适配接口等。
这些 ETL 工具，也可以作为数据同步(尤其是全量同步)的工具，通常是根据 ID ，或者最后更新时间等，进行处理。
Binlog 是实时增量工具， ETL 工具做辅助。通常一个数据同步功能，需要多个组件的参与，他们共同组成一个整体。
通讯

本文插图
推荐：HTTP+Json ，方便调试。高性能要求可选二进制协议。
Java 中， Netty 已经成为当之无愧的网络开发框架，包括其上的 socketio(不要再和我提 mina 了) 。
对于 HTTP 协议，有 common-httpclient ，以及更加轻量级的工具 Okhttp 来支持。
对于一个 RPC 来说，要约定一个通讯方式和序列化方式。 Json 是最常用的序列化方式，但是传输和解析成本大， XML 等文本协议与其类似，都有很多冗余的信息;Avro 和 Kryo 是二进制的序列化工具，没有这些缺点，但调试不便。
RPC 是远程过程调用的意思，其中， Thrift、Dubbo、gRPC 默认都是二进制序列化方式的 Socket 通讯框架;Feign、Hessian 都是 Onhttp 的远程调用框架。
对了， gRPC 的序列化工具是 Protobuf ，一个压缩比很高的二进制序列化工具。
通常，服务的响应时间主要耗费在业务逻辑以及数据库上，通讯层耗时在其中的占比很小。可以根据自己公司的研发水平和业务规模来选择。
微服务

本文插图
推荐：

注册中心：Consul 。
网关：Nginx+Gateway 。
配置中心：Apollo 。
调用链：Skywalking 。
熔断：Resilience4j 。

我们不止一次说到微服务，这一次我们从围绕它的一堆支持框架，来窥探一下这个体系。是的，这里依然是在说 Spring Cloud 。
默认的注册中心 Eureka 不再维护， Consul 已经成为首选，它使用 Raft 协议开发开箱即用。 Nacos、Zookeeper 等，都可以作为备选方案。其中 Nacos 带有后台，比较适合国人使用习惯。
熔断组件，官方的 Hystrix 也已经不维护了。推荐使用 Resilience4j ，最近阿里的 Sentinel 也表现强劲。
对于调用链来说，由于 OpenTracing 的兴起，有了很多新的面孔。推荐使用 Jaeger 或者 Skywalking 。 Spring Cloud 集成的 Sleuth+Zipkin 功能稍弱，甚至不如传统侵入式的 Cat 。
配置中心是管理多环境配置文件的利器，尤其在你不想重启服务器的情况下进行配置更新。