企业低成本万能架构

企业软件应用架构层出不穷（这里的应用架构是指偏后端服务的软件架构）每个企业由各自业务形态，技术栈，技术路线，技术实力不同，各自架构方案，技术选型各有各的不同，千姿百态，正所谓：“百花齐放，尽吐芬芳”。

没有最好架构，只有当前最适合的架构方案，也没有完美架构，只有持续迭代演进的架构。

有没有一种万能通用应用服务软件架构呢？今天我们来聊聊我眼中的“万能”架构。

所谓万能，也不是真正的万能！

我这里提两个指标：

1、适用于大多数企业的大多数业务场景（70%以上）；

2、在满足业务条件下企业投入成本要求最小化，包括：（软硬件成本+人员学习成本+实施成本+运维成本）。

 

1、极简之万能架构

应用服务+MySQL+Redis+ES

这是极简的架构搭配基本上可以满足70~80%的企业应用业务场景，应用服务开发语言不限，企业根据自己团队善长技术方向就行，例如：PHP，C#，JAVA，go，python，ruby等。

MYSQL开源免费、稳定、可靠、安装简单，只要搞过web开发的人都熟悉，接入成本极低、运维成本较低（相比其他关系型数据库）；

Redis开源免费、高性能、稳定、可靠，基本搞过软件开发的人都会，接入成本、运维成本极低；

ElasticSearch开源免费、高性能、稳定、可靠，大多数开发人员都会使用，接入成本低，运维成本有那么点高。

MYSQL+Redis+ElasticSearch这三者组合，可以满足大多数业务应用场景，一般企业都可以考虑这种架构方式，简单高效。真的没有必要追求复杂的架构。

Redis除了高性能之处，还经常可以用来做分布式锁，缓存一些少量热点的数据，比如数据字典。

ES安装稍微复杂一点，但也没有多复杂，机器性能要求高一些，要求稍微高配一点的机器，内存大和高速SSD硬盘。它在查询分页数据列表，查询亿级数据量毫秒级（当然是要求正确建立分片和有效索引前提下）。

如下图所示：

以上架构可以号称最简单的万能架构，一般在万级以内QPS可以顶得住的，而绝大多数企业应用实际上也没有那么大的并发量级；

但万一有些特殊的业务场景并发远不止是万级的，特别面向互联网消费者用户量级就要高得多了，如：10万级、百万级、千万级怎么办？

存在一些问题：

（1）应用怎么实现水平扩展？

（2）三大件单点风险比较高，怎么做高可用？

架构需要进一步扩展

2、极简万能架构之二

MySQL+Redis+ES+Nginx (四个组件配置群集版)

这个架构增加了Nginx代理，从而可以实现应用服务水平扩展的能力，而nginx本身是开源免费，高性能、稳定，安装配置简单特点，非常适合在高并场景中做反向代理应用。

而Nginx本身也可配置多节点，通过虚拟IP即VIP配置集群，实现高可用。

同时ES和Redis都可以配置部署多个节点，从而实现集群版本，这两个组件本身单机性能非常强悍。加上集群配置，几乎可以高枕无忧一段时间了。

另外MySQL可以配置集群版本，1主多从，为什么要用1主呢？因为单一主节点简单：程序实现简单、写入简单、配置部署也简单、运维也简单。高并发场景一般都是查多写少。

推荐：MySQL+Redis+ES+Nginx 四件套加集群版本，简单高效！

这种架构也能满足绝大多数企业应用的高并发场景。所以读多的情况下10万级以下QPS可以顶住的。

一般企业应用如果日常业务能达到10万级QPS，访问量算已经非常大的了，能达到这个量级，业务量够大，收入不是问题，也不怕这点投入了。

 

但是凡事有万一，万一真的是写多了怎么办，主库一个节点根本扛不住怎么办？

存在问题：

（1）一个主库写入是不够的？在高并发写入的时候肯定扛不住。

 

3、多读多写方案一

Mysql部署多主多从

读多上面分析过，问题不大，写多呢？方案很多，可以使用mysql多主架构部署，但是运维和部署复杂度也会高很多。若没有那么大的实际业务量的要求，建议谨慎考虑清晰！

应用程序不用太多改动，相当于主库多一层代理，对上层调用透明。

多主存在的问题：

1、主与主双向同步复制问题；

2、主从复制同步问题

 

主从复制

MySQL主从复制工作流程

 

主要⽬的是实现数据库读写分离，写操作访问主数据库，读操作访问从数据库，从⽽使数据库具有更强⼤的访问负载 能⼒，⽀撑更多的⽤⼾访问。 它的主要的复制原理是：当应⽤程序客⼾端发送⼀条更新命令到数据库的时候，数据库会把这条更新命令同步记录到Binlog中，然后由另外⼀个线程从Binlog中读取这条⽇志，然后通过远程通讯的⽅式将它复制到从服务器上⾯去，从服务器获得这条更新⽇志后，将其加⼊到⾃⼰的Relay log中，然后由另外⼀个SQL执⾏线程从Relay log中读取这条新的⽇志，并把它在本地的数据库中重新执⾏⼀遍。
这样当客⼾端应⽤程序执⾏⼀个update命令的时候，这个命令会在主数据库和从数据库上同步执⾏，从⽽实现了主数据库向从数据库的复制，让从数据库和主数据库保持⼀样的数据。

 

主主复制

主主复制⽅案是指两台服务器都当 作主服务器，任何⼀台服务器上收到的写操作都会复制到另⼀台服务器上。

 

 

如上图所示，当客⼾端程序对主服务器A进⾏数据更新操作的时候，主服务器A会把更新操作写⼊到Binlog⽇志中。然后Binlog会将数据⽇志同步到主服务器B，写⼊到主服务器的Relay log中，然后执Relay log，获得Relay log中的更新⽇志，执⾏SQL操作写⼊到数据库服务器B的本地数据库中。

B服务器上的更新也同样通过Binlog复制到了服务器A的Relay log中，然后通过Relay log将数据更新到服务器A中。

通过这种⽅式，服务器A或者B任何⼀台服务器收到了数据的写的操作都会同步更新到另⼀台服务器，实现了数据库主主复制。主主复制可以提⾼系统的写高可⽤。但处理逻辑、部署、运维会复杂很多。

主主复制存在的问题：

（1）不要对两个数据库同时进⾏数据写操作，因为这种情况会导致数据冲突。 
（2）复制只是增加了数据的读并发处理能⼒，并没有增加写并发的能⼒和系统存储能⼒。
（3）更新数据表的结构会导致巨⼤的同步延迟。

 

4、多读多写方案二

MySQL分库分表

MySQL分库分表也是相当成熟的方案，可以用一些开源的中间件如：MyCat，ShardingJdbc等进行代理。查询和写入都实现分库分表，写入和查询性能能够实现较大的提升。

因为数据都散列到各个分片，数据规模打散。利用MyCat和ShardingJdbc组件作代理。

 

相应带的问题是：

1、应用程序处理逻辑会变得比较复杂；

2、数据打散之时，数据运营和运维会带来很多的不方面（例如：发现数据有一些问题，想上去查询分析一下数据，这就比较麻烦了，得从程序逻辑解析打散的算法，然后聚合起来再去查询）。

 

5、多读多写方案三

增加其他中间件缓冲

在写入多的情况，如果不想拆分数据库，可以增加一些中间来做缓解。

可以增加MQ组件，错峰填谷，异步排队慢慢处理，同时也需要增加熔断限制的组件，比如Sentinel组件，免费开源、配置使用简单、学习成本低。

Sentinel以流量为切入点，从流量控制、流量路由、熔断降级、系统自适应过载保护、热点流量防护等多个维度保护服务的稳定性。当然上面其他方案也可以增加此组件，根据业务场景需要选择是否使用，并不会冲突。

增加MQ组件（可以选择RabbitMQ或RocketMQ都是免费开源的），一方面可以解耦服务间的依赖，另一方面起到限流缓冲作用，让写入排队慢慢写入，不至于冲跨数据库。

 

增加Sentinel起到限流熔断降级作用，高并发条件下不至于服务被冲跨，但本质上只是保持服务高可用，并没有整个体上提高系统的并发量、吞吐量。

如果在百万级别以上并发量下，虽然系统可以实现高可用，但是大部分用户限流了阻挡在外面，用户体验并不友好！

 

6、多读多写方案四

使用NOSQL数据库替换

NOSQL数据库也有很多可选方案，这里推荐使用TIDB，不是广告！我们在实际生产业务使用验证过，按官方最低配置（一个集群最小要求7台高配服务器）；

TIDB高性能查询自然不用说本来就高性能（比Mysql高效得多了），我们写入并发TPS可以去到2万左右，这个已经是一个相当大的并发量。如果并发再提升也可以随时扩展。

TIDB是国产数据库，免费开源，使用KV底层实现上层关系型数据库，设计理念非常先进。TIDB本身就是定位为分布式数据库，可以根据自己业务量实现水平扩展，这是个相当了不起的产品。

使用TIDB的好处有哪些？

1、最大好处是原来的业务端代码基本不用改，切换数据源就可以了，100%兼容Mysql语法，当然如果你使用了Mysql一些特殊语法，如存储过程，特殊函数是不支持的。

2、可以承载高并发业务场景数据库水平扩展，多写多读都可以。

 这种架构呢，基本在百万级并发量也是能扛得住的，因为应用可以实现水平扩展，数据库也可以实现水平扩展，可以说是解决了两大核心关键问题。

一般业务并发访问量在百万级别的体量，都推荐使用这种架构，总体算下来成本也不高。还是那个三原则：简单、高效、低成本。

当然坏处也有的，就是需要增加一笔不少的服务器资源费用，学习有一定成本、运维也有一定成本。

不过话说回来，如果说系统真有那么大流量说明公司业务大，说明业绩很好，这些投入非常值得的。

 

7、微服务体系下极简之万能架构

在SpringCloud体系下组件非常多，采用最简基本组件注册中心、配置中心和网关，其最简组合：Eureka+Gateway+Redis+Mysql+MQ

当然注册中心推荐nacos来代替。nacos是阿里团队免费开源、稳定、也同时支持多种协议（http、dubbo等）；nacos除了注册中心作用之外自带配置中心，这样好个好处是减少额外部署一个配置中心。

（1）最简版SpringCloud微服务分层示意

（2）我们公司的微服务架构

这是几年前我们公司搭的微服务架构，这几年来没有什么太大改变。跑了几年下来也说明架构是稳定可靠的。

不过近期在搞云原生，是有较大改变，因还没有上线，没有验证生产实际情况下，所以新的架构还等一段时间再来分享。

 

（3）微服务混合体架构

这个架构是混合springcloud和dubbo两种微服务架构，曾经在我们的系统架构中存活过一段时间。因为有历史，早期使用了dubbo，后面改用SpringCloud体系。中间存在切换周期，其实一直保持两种微服务架构存在也是可以的。只不是调用者可能会混乱，当时我们为保持团队统一认识，减少误用的情况下，最后全切了SpringCloud体系。

 

8、总结

1、软件世界里没有“万金油”，选择低成本最适合于业务场景的应用软件架构就达到目的了；

2、所谓万能架构也是带有条件的，就是根据自己业务量规模大小、技术条件选择最低成本架构方案；

3、微服务架构还有很多其他方案选择，目前来说Springcloud是相对比较低成本的架构设计方案。

• 还没有人评论，欢迎说说您的想法！