高性能高并发服务瓶颈和突破思路.docxVIP

高性能高并发服务的瓶颈及突破思路服务的瓶颈有哪些通常来说程序的定义是算法+数据结构+数据，算法简单的理解就是一种计算方式，数据结构顾名思义是一种存储组织数据的结构，这两者体现了程序需要用到的计算机资源涉及到CPU资源、内存资源，而数据部分除了内存资源，往往还可能涉及到硬盘资源，甚至是彼此之间传输数据时会消耗网络(网卡)资源。当我们搞清楚程序运行起来时涉及哪些资源后，就可以更好地分析我们的服务中哪些可能是临界资源。所谓临界资源就是多个进程(线程)并发访问某个资源时，该资源同只能服务某个或者某些进程(线程)。服务的瓶颈主要就是在这些临界资源上，还有一些资源原本并不是临界资源，比如内存在一开始是够的，但是因为连接数或者线程数不断的增多，最终导致其成为临界资源，其他的CPU、磁盘、网卡其实和内存一样，在访问量增大以后一样都可能会成为瓶颈。所以怎么做到高性能高并发的服务，简单地说就是找到服务的瓶颈，在合理的范围内尽可能的消除瓶颈或者降低瓶颈带来的影响，再通俗一点的说就是资源总量不够就加资源，确切的说是什么资源不够就加什么资源，同时尽量降低单次访问的资源消耗，做到在资源总量一定的情况下有能力支撑更多的访问。如何提升服务的并发及性能1. 数据拆分图1 单数据实例改成数据库集群最典型的一个临界资源就是数据库，数据库在一个大访问量的系统中往往是最薄弱的一环，因为数据库本身的服务能力是有限的，以MySQL为例，可能MySQL可以支持的并发连接数可能也就几千个，假设是3000个，如果一个服务对其数据库的并发访问如果超过了3000，有部分访问可能在建立连接的时候就失败了。在这种情况下，需要考虑的是如何将数据进行分片，引入多个MySQL实例，增加资源，如图1所示。数据库这个临界资源通过数据拆分的方式，由原来的一个MySQL实例变成了多个MySQL实例，这种情况下数据库资源的整体并发服务能力自然提升了，同时由于服务压力被分散，整个数据库集群表现出来的性能也会比单个数据库实例高很多。存储类的解决思路基本是类似的，都是将数据拆分，通过引入多个存储服务实例提升整体存储服务的能力，不管对于SQL类的还是NoSQL类的或文件存储系统等都可以采用这个思路。2、服务拆分图2 服务拆分应用程序自身的服务需要根据业务情况进行合理的细化，让每个服务只负责某一类功能，这个思想其实是和微服务思想类似。一句话就是尽量合理地将服务拆分，同时有一个非常重要的原则是让拆分以后的同类服务尽量是无状态或弱关联，这样就可以很容易进行水平扩展，如果拆分以后的同类服务的不同实例之间本身是有一些状态引起彼此非常强的依赖，比如彼此要共享一些信息这些信息又会彼此影响，那这种拆分可能就未必非常的合理，需要结合业务重新进行审视。当然生产环节上下游拆分以后不同的服务彼此之间的关联又是另外一种情形，因为同一个生产环节上往往是走完一个服务环节才能进入下一个服务环节，相当于有多个串行的服务，任何一个环节的服务都有可能瓶颈，所以需要拆分以后针对相应的服务进行单独优化，这是拆分以后服务与服务之间的关系。假设各个同类服务本身是无状态或者弱依赖的情况下，针对应用服务进行分析，不同的应用服务不太一样，但是通常都会涉及到内存资源以及计算资源，以受内存资源限制为例，一个应用服务能承受的连接数是有限的(连接数受限)，另外如果涉及上传下载等大量数据传输的情况网络资源很快就会成为瓶颈(网卡打满)，这种情况下最简单的方式就是同样的应用服务实例部署多份，达到水平扩展，如图2所示。实际在真正拆分的时候需要考虑具体的业务特点，比如像京东主站这种类型的网站，在用户在访问的时候除了加载基本信息以外，还有商品图片信息、价格信息、库存信息、购物车信息以及订单信息发票信息等，以及下单完成以后对应的分拣配送等配套的物流服务，这些都是可以拆成单独的服务，拆分以后各个服务各司其职也能做更好的优化。服务拆分这件事情，打个不是特别恰当的比方，就好比上学时都是学习，但是分了很多的科目，高考的时候要看总分，有些同学会有偏科的现象，有些科成绩好有些科成绩差一点，因为分很多科目所以很容易知道自己哪科是比较强的、哪科是比较弱的，为了保证总体分数最优，一般在弱的科目上都需要多花点精力努力提高一下分数，不然总体分数不会太高。服务拆分也是同样的道理，拆分以后可以很容易知道哪个服务是整体服务的瓶颈，针对瓶颈服务再进行重点优化比等就可以比较容易的提升整体服务的能力。3、适当增长服务链路，尽量缩短访问链路，降低单次访问的资源消耗在大型的网站服务方案上在各种合理拆分以后，数据拆分以及服务拆分支持扩展只是其中的一部分工作，之后还要根据需求看看是否需要引入缓存CDN之类的服务，我把这个叫做增长服务链路，原来直接打到数据库的请求，现在可能变成了先打到缓存再打到数据库，对整个服务链路长度来说