企业软件应用架构层出不穷（这里的应用架构是指偏后端服务的软件架构）每个企业由各自业务形态，技术栈，技术路线，技术实力不同，各自架构方案，技术选型各有各的不同，千姿百态，正所谓：“百花齐放，尽吐芬芳”。
没有最好架构，只有当前最适合的架构方案，也没有完美架构，只有持续迭代演进的架构。
有没有一种万能通用应用服务软件架构呢？今天我们来聊聊我眼中的“万能”架构。
所谓万能，也不是真正的万能！
我这里提两个指标：
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主呢？因为单一主节点简单：程序实现简单、写入简单、配置部署也简单、运维也简单。高并发场景一般都是查多写少。
所以这种也能满足绝大多数企业应用的高并发场景。所以读多的情况下10万级以下QPS可以顶住的。达到10万级QPS，访问量算已经非常大的了，能达到这个量级，企业收入强大了，也不怕投入了。
但是凡事有万一，万一真的是写多了怎么办，主库一个节点根本扛不住怎么办？
存在问题：
（1）一个主库写入是不够的？在高并发写入的时候肯定扛不住。
3、多读多写方案一
Mysql部署多主多从
读多上面分析过，问题不大，写多呢？方案很多，可以使用mysql多主架构部署，但是运维和部署复杂度也会提高很多。应用程序不用太多改动，相当于主库多一层代理，对上层调用透明。
多主存在的问题：
1、主与主双向同步复制问题；
2、主从复制同步问题
这里需要展开描述一下主主双向同步的问题。加个flag晚上有空再补充一下，现在有点忙。
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的好处呢，原来的业务端代码基本不用改，切换数据源就可以了，100%兼容Mysql语法，当然如果你使用了Mysql一些特殊语法，如存储过程，特殊函数是不支持的。
这种架构呢，基本在百万级并发量也是能扛得住的，因应用可以实现水平扩展，数据库也可以实现水平扩展，可以说是解决了两大核心关键问题。
当然坏处也有的，就是需要增加一笔不少的服务器资源费用，学习使用、运维有一定成本。说回来，如果说系统真有那么大流量说明公司业务大，业绩很好，也不必要在呼这点投入。
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是相对成本比较低架构设计方案。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.e1idc.net
