寄语
作者对于技术学习是希望大家是以思考的方式去探索学习，然后形成自己的能力思维。我相信所有的事物的发展必然是一步步演进的，只有真正能了解这个过程才算是掌握了知识。
三高架构
什么是三高架构？所谓三高，就是高并发，高可用，高性能。这是互联网行业内人都了解得。三高问题的产生是从何而来？自从有了微服务诞生，分布式服务的架构的诞生，互联网用户的急剧的增加，带来了用户的访问需求，从而就引起三高问题。场景是：
- 高并发：在较小的一段时间内，较多的用户发起访问请求
- 高可用：在任何情况下，用户发起访问请求的成功率要尽可能达到100%
- 高性能：用户发起访问请求之后，在较小的时间内用户能接收到响应
这三种情况下，用户访问量达到多少才算高并发？请求成功率达到多少才算高可用？响应请求时间达到多少才算是高性能？先不讨论解决方案，先抛出这些过程中可能会出现的问题。三高问题一般情况都不是单独产生的。
对于系统而言三高是系统的非功能性需求，这就会出现在很多时候系统上线初期没有问题，如果你没有去监控治理系统的话，很可能某一天突然就会出现问题。这个时候三个问题产生不会独立出现，比如可用性出了问题，肯定伴随有性能问题产生；并发量上升了之后，会带来稳定性和性能上的问题。
问题场景
代码问题
代码问题主要是影响性能，主要体现在IO的使用，对象的创建，逻辑的冗余，算法等等。这个就纯粹是基础知识问题。如果要避免这些问题除了要看经验外，其次就是基础知识点要扎实。但是我们可以在开发过程中有几类影响性能问题的一些点注意下：
- IO数据读取，这个在程序中不管用什么工具中间件都是最消耗性能的，所以一定要控制IO次数
- 交互逻辑和计算逻辑，在程序运行时计算的速度，也就是常用算法编写也是会影响应能。
- 网络问题，当需要传输的数据增加了，所需要网络带宽也要考虑，数据冗余不要过多
常见解决方法： 批量IO操作，SQL优化，简化响应数据，多线程处理任务，异步处理等。核心方案就是掌握好基本知识点，学会应用。
请求性能问题
这个主要体现在有些请求的性能有问题，处理起来比较消耗资源(CPU,带宽)。当并发量不高的情况下这些请求看起性能还可以，响应时间也较短。但是当请求量并发较高之后，资源的消耗就会呈直线上升，很快就会导致CPU资源不足，性能就会变差。如果没有及时处理，就会引起恶行循环。会导致服务不可用。直观现象就是可以支持的并发量不足。出现这种问题的原因首先是代码问题引起的，还有也有可能资源配置不足(JVM的参数配置)，也有可能是数据交互量过大。
请求处理速度问题
请求处理的速度直接关系可以支撑并发量的大小。这种典型的问题就是在一定时间内大量请求需要处理，然后需要处理这些请求需要分配资源。服务器的资源是有限的，当已经分配的资源还在处理请求未完成时，还有不断的请求进来，这时候就没有资源可用，新进来的请求就没有办法处理，请求和就会失败。同事当资源不足时候，大概率会导致性能也有问题，请求响应也会不及时，然后甚至引起服务不可用。
服务宕机问题
宕机是我们大家所熟知的，就由于资源不足，程序死循环，死锁等都可能会引起服务宕机。这个从理论上来讲，宕机是不可避免的问题。但是在互联网时代，服务宕机，停止服务是完全不可接受的，对于高用户量访问来说，宕机几分钟，损失就不可估计。所以针对宕机的情况，我们要只允许服务部分宕机，不能是全部宕机停止服务。
以上三类问题分别代表了高并发，高性能，高可用典型的问题。
三高解决方案
解决三高问题有多个角度去思考，首先可以从架构层面去考虑思考，其次也需要从技术层面去思考。然后随着技术的更替和需求的迭代升级， 应用一些新技术也是需要持续去跟进的。通过以上分析三高问题，都是属于量变引起质变的问题。上面的问题分析其实也基本解释了引起了什么样的质变。根本型要解决就是资源的竞争问题，不管是请求多了，还是宕机，都是资源的竞争使用问题，那么我们的核心思路就是考虑怎么去扩展我们的资源。
架构层面
集群部署
集群就是把我们提供服务的组件部署多分，可以在不同的区域(跨域)，每个区域部署个节点提供服务。提供服务的节点多了，所支撑的并发量可以多了，那么可用性也会大大提高。比如某一台机器或者某一个区域的机器宕机（停电）依然可以通过这个集群提供服务。另外根据用户分布的不同的区域，可以动态让用户请求到离他比较近的区域服务器，同样可以提高性能，就比如抢红包，如果发红包的人距离你比较远，在同等网速下，那你肯定就比离他近的人满一点点，就会抢不到。
有了集群后，那么这些集群是否提供服务，给谁提供服务，哪些地区的机器可以提供服务就需要注册中心这个组件来完成这个功能，同时注册中心它本身也是需要集群部署。
核心关键： 集群方案(主从模式,一主多从,选主)，注册中心(Zookeeper,Nacos,Redis,Eureka,Etcd)
网关服务
什么是网关？字面意思就是网络关口，就是服务的大门，所有的用户请求都需要经过。所以大部分的服务要实现三高，必然会有一个网关层面来进行全局控制。它可以控制请求的并发量，可以做监控，也可以进行流量的分发，服务集群部署后，每个区域所支撑的量会有不同，那么流量怎么分发也需要网关层面来做。比如限流(令牌桶，漏通)，熔断等算法。
核心技术：SpringCloud-Gateway(路由，断言，过滤器)
容器化部署
容器化，云原生等技术越来越多会被提到。因为这个技术越来越成为三高架构实现成本最低，效率最高的技术。容器化部署可以达到很高效的伸缩和扩展。当前发现服务已经满足不了并发请求之后可以动态的增加部署服务。当并发下降之后再停止这些服务。
核心技术：K8S(etcd,apiserver,kubernetes),Docker,OpenStacks
技术层面
缓存的使用
用户请求要提高并发量，首先就是要降低请求的响应时间，最直接方案就是降低再请求过程中请求各种资源的时间消耗(前端静态资源(CDN),页面缓存,页面压缩,减少cookie传输,后端的接口数据缓存)。
负载均衡
当我们的服务部署成集群之后，每一个区域内的请求的分布是需要可以控制的，比如正常的我们主要的机器是32G的机器，然后为了提升提高并发，不可能直接复制，在搞一台32G的机器，那么资源很浪费，这时候就需要最好能搞一台8G的作为一个缓冲，这个时候就需要通过负载均衡来保证资源利用率较高
异步处理
有时候针对一些复杂的请求我们如果采用同步的话是肯定会有阻塞请求处理的，那么这时候如果有阻塞很容易就造成资源的竞争加剧，也会导致资源的利用率降低，倒是浪费，这时候就需要考虑使用多线程，或者使用MQ来进行异步处理。
约定处理
微服务是多维度，多层次的，多组件的系统。那么这些组件之间的信息交互就会频繁。有时候为了减少服务之前频繁交互信息，可能会去采用约定去处理，就是大家统一遵守一套规范，当出现了一些问题之后，都按照约定的规范方案去做处理，这样既可以避免信息数据交互，同时也提升了性能。比如JSON协议，RAFT协议，ZAB协议。配置中心。外部配置化等都是以约定的方式作为解决方案。
另外可能还有一些由于分布式服务中为了确保业务的准确性，有一些技术，比如分布式锁，分布式事务等技术，虽然这些锁的使用降低了三高性能，但是在三高上面也有一定的要求。所以实现上也是有差别。
总结
以上是三高架构的一些思考，三高要求随着技术更新，三高的方案也会更新，但是思考解决方案的方向应该是不会变的。
三高架构的核心技术会网关，注册中心，监控，集群化，容器化 等会在后面的博客中介绍。