正文
上面的分库分表组件，都是大浪淘沙，最终的优胜品。这些组件不同于其他组件选型，方案一旦确定，几乎无法回退，所以要慎之又慎。
分库分表是小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，一个压缩比很高的二进制序列化工具。
通常，服务的响应时间主要耗费在业务逻辑以及数据库上，通讯层耗时在其中的占比很小。可以根据自己公司的研发水平和业务规模来选择。
推荐：
1.注册中心：consul
2.网关：nginx+Gateway
3.配置中心：Apollo
4.调用链：Skywalking
5.熔断：resilience4j
我们不止一次说到微服务，这一次我们从围绕它的一堆支持框架，来窥探一下这个体系。是的，这里依然是在说spring cloud。
默认的注册中心eureka不再维护，consul已经成为首选，它使用raft协议开发开箱即用。nacos、zookeeper等，都可以作为备选方案。其中nacos带有后台，比较适合国人使用习惯。
熔断组件，官方的hystrix也已经不维护了。推荐使用resilience4j，最近阿里的sentinel也表现强劲。
对于调用链来说，由于OpenTracing的兴起，有了很多新的面孔。推荐使用jaeger或者skywalking。spring cloud集成的sleuth+zipkin功能稍弱，甚至不如传统侵入式的cat。
配置中心是管理多环境配置文件的利器，尤其在你不想重启服务器的情况下进行配置更新。目前，开源中做的最好的要数apollo，并提供了对spring boot的支持。disconf使用也较为广泛。相对来说，spring cloud config功能就局限了些，用的很少。
网关方面，使用最多的就是nginx，在nginx之上，有基于lua脚本的openrestry。由于openresty的使用非常繁杂，所以有了kong这种封装级别更高的网关。
对于spring cloud来说，zuul系列推荐使用zuul2，zuul1是多线程阻塞的，有硬伤。spring-cloud-gateway是spring cloud亲生的，Spring Cloud 大力支持，基于 Spring5.0 的新特性 WebFlux 进行开发。底层网络通信框架采用的是 Netty，吞吐量高。
