什么是MYSQL微服务架构呢？先看一下面这图，点击放大
你能看懂多少是多少！ 该图不解释！
微服务是如今流行的架构，JAVA SPRING BOOT SPRING CLOUD 连微软NET 也推出了微服务架构NET CORE。
那什么是微服务架构，在谈它时我们先谈它的前身。
在2000年的时候，WEB应用主要是三大语言流行，那就是ASP,JSP,PHP
这21世纪初流行的架构是 LAMP LINUX+APACHE+MYSQL+PHP
当然JAVA 是 JSP+TOMCAT+MYSQL+LINUX；
微软是 ASP +IIS+SQL SERVER+WINDOWS；
好像这不叫架构，确实不叫架构！
程序设计 无论是ASP JSP 还是PHP 都是在一起写。 什么意思呢？
也就是说 HTML+CSS+PHP+SQL 都是一个写，都写在一起。
这带来比较多的问题 修改和扩展维护都不行。
2010年 开始 流行MVC 框架，JAVA 实现MVC框架是 SSH 和SSM。
微软是ASP.NET+C#。PHP我就不清楚了
什么是MVC呢? M是模型，V是视图，C是控制。
大意是逻辑上把展现层，业务层，控制层分离。 不在一个JSP去实现这些。这就很好了，修改和扩展都比较方便易懂，不出错了！下图是MVC横向扩展，MYSQL数据库玩的是MMM MHA PXC架构。
最近2018年开始流行的微服务，微服务是把MVC 单体应用拆成多体。
原来的MVC架构 所有的业务实现都在一个项目当中完成。就一个JAR丢进TOMCAT中去。其实我觉得单体挺好的，也没啥不好的。问题在于业务量上来了，活跃用户多了，各个产品经理的需求多了，并且要求快速上线。
如果只是业务量多了，我们可以通过LVS+NGINX 来横向扩展满足性能的要求。可快速开发，快速上线时间要求就无法满足，那怎么办呢？因为修改一个功能，需要测试团队进行全面的测试才能放心上线。
这好比一个人脚受伤了，必须躺在床上，手不能玩手机，嘴不能吃东西，眼睛不能看电视。
其实我认为微服务最重要的是特性就是其中一个服务不会影响到其他服务。一个子业务发生了BUG，不影响其他业务正常运行！
就是上面举的列子，一个人腿受伤了，居然影响其他手，嘴的功能。其他什么快速开发，快速部署都是附带的功能。
什么是微服务呢？ 就是把一个整体业务，拆成多个子业务，每个子业务都是高内聚，低耦合特性，各个子业务之间通过必要的少数接口通讯完成数据交换。其实这也叫垂直拆分！
微服务化架构，不仅是把业务拆成多个业务，而且前后端也分离。就是MVC 当中的M和V从一个项目分离出去了，V视图交给前端开发工程师完成，M交给后端开发师完成。展现层，表现层，HTML+CSS+JAVA SCRIPT 统统交给，以前是美工，现在叫前端开发工程师。而业务逻辑和数据映射SQL交给JAVA工程师完成。
当应用微服务化的时候，数据库端MYSQL是什么样的架构呢？
当今2091年流行的是 分表分库，读写分离，数据库中间件。
物理架构如下图
有三组MHA 管理的MYSQL 主从架构支撑分表分库。每个微服务对应的数据库只是在逻辑上拆了 放进在DATABASE 这样的SCHMAE下。
分表只是把大表 分拆到 三组物理MYSQL主从上。
而读写分离，只是把写放在主上，读放在从上。
这样的架构确实能满足互联网+的业务压力。看样子扩展能力如何？
只能通过HAPROX 搭建MYCAT集群，然后添加MHA的MYSQL
其实微服务架构思想是什么？ 就是一个问题不会波及到整个系统稳定运行。 上面的架构当一个SQL语句运行缓慢，导致影响整个系统的变慢。
MYSQL微服务架构应该是进行物理隔离
这样看每个微服务，每个子业务都对应一组MYSQL主从，并由MYCAT完成局部读写分离和FAIL OVER
这样的物理隔离的微服务架构，确实隔离了一个SQL影响到其他业务的系统运行。不错不错！ 当是该如何对大表进行分表分库呢？
这样架构其实抄整体分表分库，只是对微服务当中大表进行而已。其实并不是每个微服务（子业务）的表特别大，都需分表。这样架构成本比较经济！这样的架构完成 高可用，高扩展，高性能！
高可用由MYCAT的FAILOVER 机制
高扩展由HAPROXY 扩展MYCAT
高性能由MYCAT的分表分库去实现。
嗯嗯！ 那高稳定呢？上面单个微服务稳定性不很高，对运维人来说是涉及到KPI绩效钱的问题。MYCAT的性能和稳定性制约了整个稳定性，MYCAT的设置也比较复杂，发生了什么问题，会导致该服务不能正常运行。或许是GOURP JOIN SUM 。
那么我们应该把可能导致稳定性的原因分离开！不要混合在一起。
我们看上面的架构图，支持读，也支持写，还支持OLAP.我们继续拆分
如下
这图有点复杂 跟第一张图呼应！ 这架构把分表分库 与正常业务分开。
一般分表分库 大部分都是SELECT多，基本上是SUM GROUP ORDER之类。要访问全部数据后，才返回少量数据库给前端。比如我的本月消费总额。
我们把微服务的涉及到的所有表 放进左边的写集群 OLTP&OLQP。
这里大家对OLTP和OLAP都有所了解，OLTP就是在线交易，OLAP是在线分析。我觉得这个分析不是那种数据仓库之类的分析。应该涉及到客户的统计，并展现给客户看。
那OLQP有是啥呢？其实这是从OLTP分离出来的SQL类型，叫在线查询！
呵呵 有点懵了吧！ 我们把这些解释统统抛弃。防止我们思想混乱！
OLTP 就是 INSERT DELETE UPDATE DML 语句
OLAP 就是 SELECT SUM(),COUNT() GROUP BY 统计语句。
OLQP 就是 SELECT * FROM TABLE WHERE ID=XX 的Key Value语句。
完成一笔业务交易需要执行很多SQL语句，一般都是读多写少，而读当中统计性语句比较少，大部分都是KEY VALUE的查询。比如一个JAVA ADO对象GET函数就是个KV查询 返回某个用户ID的某个属性。而OLQP KV查询大部分都是根据主键ID完成的。这样OLQP的SQL语句由写集群中的从库完成！
上图架构中 所有的表结构都在写集群中，然后通过数据同步中间件CANAL 把表的数据同步到分表分库集群中，由MYCAT根据分表规则把大表拆分到物理MYSQL组当中。这样就解决跨库的自增ID问题！
并不是把所有的表同步过去，这由CANAL客户端编程，确保哪些表同步到分表分库集群中。分表分库集群对应用提供只读。
最后上图架构中 SQL_SPLIT 组件功能通过分析SQL语句把带有 SUM() COUNT,GROUP BY ORDER 的语句 并且含有特定的表名提取出来。
当然这个组件并没开发出来。不过这可以由JAVA设置多个JDBC ，由开发工程师人为提取。虽然开发工程师忙于赶进度，统统把SQL语句往写集群抛。 DBA可以在后期发现类似的语句，觉得可以放进分表分库集群，然后通知开发工程师修改下而已，举手之劳，分分钟的事情。SO EASY！
最后通过CANAL 把所有的微服务主库的数据同步到一组MYSQL，完成跨服务JOIN，避免微服务之间通讯和传数据太频繁的问题。
这样每个微服务都要设置3个JDBC源 完成不同的SQL功能！
最后还有个叫OLHP 在线大数据挖掘！MYCAT+HBASE+SPRAK。
向用户提供用户一年消费和消费商品判断用户是个什么个性的人！！