说说你们的服务架构——再说说每个环节的机器配置

  有没有真正的生产经验，一问便知。

 即使是大公司的跑龙套的，不知道系统上下的整体架构，也说不过去。可能一些专业的测试，包括机器的压测，全链路的问题演练，即使没做过，最后的测试报告多少还是要知道的。

 如果是小公司的负责架构的，这些问题肯定一清二楚。有没有生产经验，以及经验是否真实，通过服务架构，以及各个环节的资源配置，是可以体现出来的。

 是在没有做过压测，也没关系，至少去官网上看一下官方做的压力测试。

  多数情况下，一问到这个问题，很多人就开始瞎扯了..

 

springCloud微服务架构

 使用nacos作为注册中心，使用nginx作为流量网关，使用gateway作业务网关，使用fegin做服务之间的调用，使用Ribbon做服务的负载均衡，使用sentinel做限流与服务降级

 使用mysql作为主要的存储（主从架构，读写分析，分库分表）

 使用Redis做分布式锁，分布式事物，以及用来做缓存优化。

 使用Seata做分布式事物。

 使用elasticsearch做检索。

 这可能是最普通的一个微服务架构了..

 

服务拆分以后的致命问题

  单点故障问题，以及如果没有容灾机制的情况下，问题蔓延，造成雪崩。

  解决单点问题，没啥捷径，无非是集群模式，在确保任何一台机器挂掉了，都能正常提供服务。至少有一台可用，能够正常的提供服务。基本上就是通过机器冗余来解决点单故障的问题的。另外集群模式还应该包括完善的机器监控，以及服务监控，报警机制，集群中的任何一台机器挂掉了，都应该触发报警，及时去排查问题。服务也应该有监控机制，保证问题出现的时候即使发现，及时解决。

 

集群模式必不可少，那具体的机器资源呢？

  有一句话是这么说的：任何脱离机器资源谈优化都是耍流氓。任何脱离实际生产需求的架构是胡扯。非常有道理，任何的环节的资源配置，都是基于机器资源的。比方说，你的服务架构里边有网关技术，以gateway搭建的业务网关为例子，首先应该知道网关会损失一定的性能，具体是多少，看官方的压力测试，以及大公司的测试报告。然后再去评估，我的单台机器（比方说4核8G）接每秒几百的请求没什么问题，首先这几百个请求没问题，是建立在（4核心8G）部署一个业务网关的前提下的，我们需要知道。我们某个前提下的机器资源，实际的服务能力是什么。 这里4核8G机器配置按每秒600个QPS来算。如果我的系统峰值只有500QPS，实际上我部署两台（一台的冗余，来解决单点故障问题），并且此时已经溢出了。这个看你具体愿意不愿意花一台机器的代价来保证高可用。如果是非核心业务，觉得挂了就挂了，带来的损失比一台机器的价值小，那只部署一台也没什么问题。如果你的QPS有两千，还按照4核8G的配置能够处理600个QPS来说，你部署四份，也可以了，还是有一台来保障可用。多少钱解决多少问题，一点都不假，这里只花了一台机器的代价来容灾，实际上你的网关集群只能保证一台机器挂了服务不受影响。如果你愿意再花一台机器，部署五台，那么你的集群可以允许随便挂掉两台。这里只是这么说，如果是在云原生环境下，实际上是不用花额外的的机器来容灾的。还用上边的例子，如果2000QPS，就用四个服务实例就好了。通过k8s的自我恢复机制，已经扩容机制。来应对问题，也足够了。

  用到数据库是必然的，应该没有哪个服务不用数据库吧！应用的本质就是处理数据。可能用到关系型数据库mysql，非关系型数据库Redis，搜索引擎elasticsearch。那这些又分别应该部署多少呢？

  问题分开讨论，以mysql为例，这取决于你的单台机器的处理能力，已经你的业务的复杂程度，脱离生产实际，就是胡扯。如果是对添加了主键索引，表结构非常简单，并且查询就是根据主键来的。完全走索引，那可能mysql处理这个请求的时间特别的段，毫秒就返回了。如果是大表，几百万数据，你的查询条件又恰好没走索引，进行了全表扫描。那可能要几秒。这都是根据实际来定的。而我也只能给一个一般数值，不离谱的值：mysql 部署在16核32G的机器上，每秒处理几千请求问题不大。具体的，要进行压测，来看机器负载情况以及测试报告来调整机器资源。

  如果是elasticsearch 的话，我的集群是三台大内存的机器，一共有60个核心，1200G。我部署了15个节点的elasticsearch 的节点，每秒25000个读请求没有问题，集群负载已经比较高了。每秒16000的写，也没问题，此时对读有一定的影响了。我多elasticsearch用的最多，优化的最多，想要有一个毫秒级别的响应这里有一个经验值：2T数据搭配64G内存以及16个核心。

  以及子系统都应该部署多少个，也也是根据不同的业务场景，进行压测，得出你的一台机器可以处理多少个QPS。来具体的确定部署多少个服务，再加上高可用冗余的机器。

 

如果我的机器资源极限是每秒 2000个QPS怎么办？

 这个就使用服务降级了，系统只能处理2000，此时硬是来了3000个，那就只能去拒绝掉后来的1000个了。

 

并发问题，没有什么是钱解决不了

  如果你不想通过技术架构来优化，凡事都可以通过在现有的机器资源上，添加更多的机器，通过堆机器来解决问题。（可能这就是著名的人傻钱多行为..）多数不会这么干，都是通过组织架构优化，来充分的压着机器的最后一点资源。不然你以为程序员的高工资是怎么来的呢，无非就两种：一种是通过向市场要钱，靠能力要来的钱，老板吃肉，员工喝汤还是没问题的；第二种就是通过你的技术给老板省钱。本来一百台机器都无法解决的问题，你用30台解决了，省下的钱，给你加个鸡腿还是不成问题的。作为有想法的程序员，我们要清楚我们值多少钱！