从古自今所有企业公司的存在都是为了解决客户的问题。比如解决人们远程通信问题有通信设备制造商（手机和通信设备）和运用商，解决吃饭问题有餐厅，解决社会交易成本问题有阿里巴巴，解决创业者技术门槛和it成本问题有阿里云等，解决人们远程空间移动的问题有汽车制造商，所有企业都是为了解决问题而存在的。如果你的亮眼发现了一个社会普遍存在并且让很多人感觉很痛的问题，那么恭喜你你的机会来啦，哈哈哈。

问题转化成需求
     所有问题都能转化成需求吗？不是所有问题都能转化成需求，这跟时代、地理环境以及其他很多因素有关。举个栗子，中国男性剪头发的问题。中国男性剪头发在古代最多就是打理头发的问题，因为身体发肤受之父母，所以古代男性是不敢剪头发的。而当今年代则正好相反，没有几个男性敢不剪头发，于是剪头发这个问题就凸显出来了，当剪头发的问题对于现在男性来说普遍存在的时候这个问题就转化成了需求，于是就有各种理发店诞生来解决剪头发的问题。所以随着时代变迁问题就转换成了需求。
     再比如辣椒对于重庆人和杭州人来说就不一样了，对于杭州人来说不吃辣椒也没啥，所以杭州人对辣椒没有需求。而在重庆就不一样啦，本宝宝身为重庆人明显感觉到重庆人就是不吃辣椒会死星人。所以同样的问题在有的地域能转化成需求，有的地域则不能。

     还有一个问题就是普遍的问题就能转化成需求吗？很多问题普遍存在但是不够让人感觉很痛到必须解决这个问题（也就是大家所说的痛点不痛），也就不会转化成需求了。举个栗子，梳头发这个问题很普遍，不管是男孩是女每天都或多或少都有需要梳头发的问题，但是这个动作往往自己就能做的很好而且很简单。如果有个产品能做到给人自动梳头发我不认为它能卖的很好，也许这种机器还会给消费者带来更大的麻烦（比如你还得定期清洗啥的）。所以很痛的问题才能够转换成需求，然后被发现，被解决，被满足。

如何发现问题
     见识过很多身边的创业的小伙伴（我学长，身边离职的同事，离职的师兄，大学同班同学，陌生的但是有过交流的创业者），千奇百怪的idea（当然都是为了解决某一领域的问题的idea），有做美家帮的（解决指甲油厂商跟美甲店之间信息不对称的问题），有做个性化定制平台的（解决广大用户到厂商定制个性化服饰、家电、汽车等问题），有开包子铺的（解决上班族节省早餐时间问题），有开健身房的（解决白领男女身材自信问题），还有做手机终端真实校验的（解决羊毛党问题的）。无一例外他们都有一双会发现问题的亮眼（当然还得有解决问题的团队和资金）。
   顺便叽歪下咱中间件做的上云的事情本质上跟外面的创业者创业是一样一样的，只不过咱是背靠强大的阿里和阿里云平台，能有机会接触到外部客户快速发现企业客户遇到的一些问题痛点，然后利用现有的中间件技术和集团资源以及品牌去解决用户的问题。而外部的创业者发现一个社会问题的想要成立公司或者团队去解决这个问题的时候就没那么幸运了，解决问题所需的资源（人才和其他资源比如资金）就得自己苦逼逼的拉风投和寻找合伙人了。而且外部创业者没有阿里这种品牌的光环笼罩，在取得客户信任的时候会显得劣势些。
    那他们的亮眼是怎么发现这个社会存在的问题，并且分析这些问题能转化成需求，最终坚信自己要去解决这些问题的呢？
     据我个人浅薄的认知和观察哈，发现问题有三种途径。第一种是你自己直接面对广大的个人或者企业去问问他们有没有遇到什么问题（这听起来貌似就是废话）。第二种是向资讯公司去购买数据，他们有比较丰富的用户需求调研数据。第三种就是观察别的公司在提供什么服务（也就是看看别人的创业idea）来间接知晓需求。
     咱中间件以我的粗浅了解的话一般是通过第一种和第三种方法去收集需求的。也就是通过直接跟用户沟通以及研究竞争对手提供的服务（竞争对手提供了这项服务说明它调研过市场有这个需求）见来收集需求。随着中间件客户群体规模由集团内扩大到阿里云几十万企业客户，未来甚至扩大到中国4000万中小企业，再在遥远的未来甚至扩大到全球数亿家企业，中间件能够发现的用户的问题将可能越来越多，解决问题的机会相应也会增多，未来不可限量。总之所有企业都是为了解决问题而存在。

【问题描述】
 
在前后端彻底分离的情况下，当我们的前端通过Ajax访问某个后台提供的接口地址的时候，浏览器会提示错误（通过查看控制台查看），并且不能看到微信授权后的结果。总而言之就是出现了跨域问题。
 
【第一种解决方法】
 
后台代码不要企图一次性完成所有的授权服务并且直接返回一个包含授权成功后获得的用户信息的Json数据，因为这样做虽然后台容易实现了但是前端却会遇到跨域的问题。
 
解决方法就是分步完成，首先我们访问前台，前台通过ajax技术访问后台，后台访问微信端数据，特别注意这个时候我们填写的回调地址是前端的地址也就是一个html地址，然后前台拿到了数据之后再次ajax提交给后台，后台再次处理，与微信端打交道，然后再次……
 
总而言之就是把授权这份工作分步骤完成并且这个分步骤是前后端还有微信端都需要参与的。
 
这种方法需要注意的是前后端事先要约定好回调地址究竟是后台的哪个地址，不可改变。如果改变的话后台的代码或者配置文件也需要改变。
 
【第二种解决方法】
 
这种方法同样需要一份协议：前后端需要约定好授权成功后返回的前端地址。也就是说，用户直接访问的是后台授权的地址，后台授权过程中与微信端进行交互的过程前台不参与，授权成功后，后台将会跳转到某一个前端的地址，这个地址必须是事先约定好的，前端在这个地址上书写解析数据类型的代码即可。如果前端的这个地址改变的话，后台同样需要修改java代码或者是配置文件。（注：授权成功后前后端交互有几种方式，可以考虑后台用写url的方式传递数据给前端，也可以考虑写入session域，然后由前台被访问时ajax从后台中拿到session域中的数据）
 
总而言之就是授权过程中前端浑然不知，知道用户访问前台的时候前台才会调用相应的js函数进行数据的获取或者解析。
 
我个人比较喜欢第二种方式，但是第一种方式也很不错。如果有遇到什么问题欢迎交流。
 
有一个比较具体的授权例子(java），可以参考一下https://blog.csdn.net/smileyan9/article/details/82714610

Zabbix是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级的开源解决方案zabbix能监控各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题 
 
Zabbix由2部分构成，zabbix server与可选组件zabbix agent
 
Zabbix server 可以通过SNMP ，zabbix agent ，ping 端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能
 
zabbix agent（代理）需要安装在被监视的目标服务器上，它主要完成对硬件信息或与操作系统有关的内存，CPU等信息的收集。
 
zabbix server可以单独监视远程服务器的服务状态；同时也可以与zabbix agent配合，可以轮询zabbix agent主动接收监视数据（agent方式），同时还可被动接收zabbix agent发送的数据（trapping方式）。
 
另外zabbix server还支持SNMP (v1,v2)，可以与SNMP软件(例如：net-snmp)等配合使用。
 
要想搭建一个Zabbix的工作环境，需要从服务器入手。与服务器通信，管理员需要使用一个Zabbix前端界面，与Zabbix服务器和数据库进行通信。三个关键（界面、服务器和数据库）可以安装在同一台服务器上，
 
Zabbix主要功能：
 
- CPU负荷
 
- 内存使用
 
-磁盘使用
 
- 网络状况
 
- 端口监视
 
- 日志监视。
 
Zabbix运行条件：
 
Server：Zabbix Server需运行在LAMP（Linux+Apache+Mysql+PHP）环境下，对硬件要求低。
 
Agent：目前已有的agent基本支持市面常见的OS，包含Linux、HPUX、Solaris、Sun、windows。
 
SNMP：支持各类常见的网络设备
 
Zabbix功能
 
　具备常见的商业监控软件所具备的功能（主机的性能监控、网络设备性能监控、数据库性能监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制）支持自动发现网络设备和服务器；支持分布式，能集中展示、管理分布式的监控点；扩展性强，server提供通用接口，可以自己开发完善各类监控。
 
Server：指安装zabbix服务的服务器（以下简称服务器端），是最重要的部份，主要安装在linux系统上（支持多种操作系统），采用mysql存储监控数据并使用apache+php的方式呈现。
 
 
 
Agent：指安装在被监控设备上的zabbix代理（以下简称代理），被监控设备上的数据由代理收集后统一上传到服务器端由服务器端收集、整理并呈现。
 
 
 
SNMP：也是agent的一种，指支持SNMP协议的设备（也可以是服务器），通过设定SNMP的参数将相关监控数据传送至服务器端（大部份的交换机、防火墙等网络设备都支持SNMP协议）。　SNMP协议主要用在对网络设备的监控方面，
 
SNMP协议主要用在对网络设备的监控方面，如交换机、防火墙等。首先需要在被监控设备上启用SNMP协议（图四七），然后在zabbix中增加被监控的主机。对于未找到snmp模板的设备就需要自己手动添加item，这里通过snmp指令查询到相关值，然后根据实际情况定制自己所需要item。

1 C10K问题
大家都知道互联网的基础就是网络通信，早期的互联网可以说是一个小群体的集合。互联网还不够普及，用户也不多。一台服务器同时在线100个用户估计在当时已经算是大型应用了。所以并不存在什么C10K的难题。互联网的爆发期应该是在www网站，浏览器，雅虎出现后。最早的互联网称之为Web1.0，互联网大部分的使用场景是下载一个Html页面，用户在浏览器中查看网页上的信息。这个时期也不存在C10K问题。
Web2.0时代到来后就不同了，一方面是普及率大大提高了，用户群体几何倍增长。另一方面是互联网不再是单纯的浏览万维网网页，逐渐开始进行交互，而且应用程序的逻辑也变的更复杂，从简单的表单提交，到即时通信和在线实时互动。C10K的问题才体现出来了。每一个用户都必须与服务器保持TCP连接才能进行实时的数据交互。Facebook这样的网站同一时间的并发TCP连接可能会过亿。

 
腾讯QQ也是有C10K问题的，只不过他们是用了UDP这种原始的包交换协议来实现的，绕开了这个难题。当然过程肯定是痛苦的。如果当时有epoll技术，他们肯定会用TCP。后来的手机QQ，微信都采用TCP协议。

这时候问题就来了，最初的服务器都是基于进程/线程模型的，新到来一个TCP连接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多进程。如果是C10K就要创建1万个进程，那么操作系统是无法承受的。如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook，Google，雅虎才有财力购买如此多的服务器。这就是C10K问题的本质。

 
实际上当时也有异步模式，如：select/poll模型，这些技术都有一定的缺点，如selelct最大不能超过1024，poll没有限制，但每次收到数据需要遍历每一个连接查看哪个连接有数据请求。


2 解决方案
解决这一问题，主要思路有两个：一个是对于每个连接处理分配一个独立的进程/线程；另一个思路是用同一进程/线程来同时处理若干连接。

2.1 每个进程/线程处理一个连接
这一思路最为直接。但是由于申请进程/线程会占用相当可观的系统资源，同时对于多进程/线程的管理会对系统造成压力，因此这种方案不具备良好的可扩展性。
因此，这一思路在服务器资源还没有富裕到足够程度的时候，是不可行的；即便资源足够富裕，效率也不够高。
问题：资源占用过多，可扩展性差。

2.2 每个进程/线程同时处理多个连接（IO多路复用）
传统思路
最简单的方法是循环挨个处理各个连接，每个连接对应一个 socket，当所有 socket 都有数据的时候，这种方法是可行的。
但是当应用读取某个 socket 的文件数据不 ready 的时候，整个应用会阻塞在这里等待该文件句柄，即使别的文件句柄 ready，也无法往下处理。
  

   
思路：直接循环处理多个连接。
   
问题：任一文件句柄的不成功会阻塞住整个应用。
  
select
要解决上面阻塞的问题，思路很简单，如果我在读取文件句柄之前，先查下它的状态，ready 了就进行处理，不 ready 就不进行处理，这不就解决了这个问题了嘛？
于是有了 select 方案。用一个 fd_set 结构体来告诉内核同时监控多个文件句柄，当其中有文件句柄的状态发生指定变化（例如某句柄由不可用变为可用）或超时，则调用返回。之后应用可以使用 FD_ISSET 来逐个查看是哪个文件句柄的状态发生了变化。
这样做，小规模的连接问题不大，但当连接数很多（文件句柄个数很多）的时候，逐个检查状态就很慢了。因此，select 往往存在管理的句柄上限（FD_SETSIZE）。同时，在使用上，因为只有一个字段记录关注和发生事件，每次调用之前要重新初始化 fd_set 结构体。
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

  

   
思路：有连接请求抵达了再检查处理。
   
问题：句柄上限+重复初始化+逐个排查所有文件句柄状态效率不高。
  
poll
poll 主要解决 select 的前两个问题：通过一个 pollfd 数组向内核传递需要关注的事件消除文件句柄上限，同时使用不同字段分别标注关注事件和发生事件，来避免重复初始化。
int poll(struct pollfd *fds, nfds_t nfds, int timeout);

  

   
思路：设计新的数据结构提供使用效率。
   
问题：逐个排查所有文件句柄状态效率不高。
  
epoll
既然逐个排查所有文件句柄状态效率不高，很自然的，如果调用返回的时候只给应用提供发生了状态变化（很可能是数据 ready）的文件句柄，进行排查的效率不就高多了么。
epoll 采用了这种设计，适用于大规模的应用场景。
实验表明，当文件句柄数目超过 10 之后，epoll 性能将优于 select 和 poll；当文件句柄数目达到 10K 的时候，epoll 已经超过 select 和 poll 两个数量级。
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

  

   
思路：只返回状态变化的文件句柄。
   
问题：依赖特定平台（Linux）。
  
因为Linux是互联网企业中使用率最高的操作系统，Epoll就成为C10K killer、高并发、高性能、异步非阻塞这些技术的代名词了。FreeBSD推出了kqueue，Linux推出了epoll，Windows推出了IOCP，Solaris推出了/dev/poll。这些操作系统提供的功能就是为了解决C10K问题。epoll技术的编程模型就是异步非阻塞回调，也可以叫做Reactor，事件驱动，事件轮循（EventLoop）。Nginx，libevent，node.js这些就是Epoll时代的产物。
select、poll、epoll具体原理详解，请参见：《聊聊IO多路复用之select、poll、epoll详解》。
libevent
由于epoll, kqueue, IOCP每个接口都有自己的特点，程序移植非常困难，于是需要对这些接口进行封装，以让它们易于使用和移植，其中libevent库就是其中之一。跨平台，封装底层平台的调用，提供统一的 API，但底层在不同平台上自动选择合适的调用。
按照libevent的官方网站，libevent库提供了以下功能：当一个文件描述符的特定事件（如可读，可写或出错）发生了，或一个定时事件发生了，libevent就会自动执行用户指定的回调函数，来处理事件。目前，libevent已支持以下接口/dev/poll, kqueue, event ports, select, poll 和 epoll。Libevent的内部事件机制完全是基于所使用的接口的。因此libevent非常容易移植，也使它的扩展性非常容易。目前，libevent已在以下操作系统中编译通过：Linux，BSD，Mac OS X，Solaris和Windows。
使用libevent库进行开发非常简单，也很容易在各种unix平台上移植。一个简单的使用libevent库的程序如下：


3 协程（coroutine）
随着技术的演进，epoll 已经可以较好的处理 C10K 问题，但是如果要进一步的扩展，例如支持 10M 规模的并发连接，原有的技术就无能为力了。
那么，新的瓶颈在哪里呢？
从前面的演化过程中，我们可以看到，根本的思路是要高效的去阻塞，让 CPU 可以干核心的任务。所以，千万级并发实现的秘密：内核不是解决方案，而是问题所在！
这意味着：

 
不要让内核执行所有繁重的任务。将数据包处理，内存管理，处理器调度等任务从内核转移到应用程序高效地完成。让Linux只处理控制层，数据层完全交给应用程序来处理。

当连接很多时，首先需要大量的进程/线程来做事。同时系统中的应用进程/线程们可能大量的都处于 ready 状态，需要系统去不断的进行快速切换，而我们知道系统上下文的切换是有代价的。虽然现在 Linux 系统的调度算法已经设计的很高效了，但对于 10M 这样大规模的场景仍然力有不足。
所以我们面临的瓶颈有两个，一个是进程/线程作为处理单元还是太厚重了；另一个是系统调度的代价太高了。
很自然地，我们会想到，如果有一种更轻量级的进程/线程作为处理单元，而且它们的调度可以做到很快（最好不需要锁），那就完美了。
这样的技术现在在某些语言中已经有了一些实现，它们就是 coroutine（协程），或协作式例程。具体的，Python、Lua 语言中的 coroutine（协程）模型，Go 语言中的 goroutine（Go 程）模型，都是类似的一个概念。实际上，多种语言（甚至 C 语言）都可以实现类似的模型。
它们在实现上都是试图用一组少量的线程来实现多个任务，一旦某个任务阻塞，则可能用同一线程继续运行其他任务，避免大量上下文的切换。每个协程所独占的系统资源往往只有栈部分。而且，各个协程之间的切换，往往是用户通过代码来显式指定的（跟各种 callback 类似），不需要内核参与，可以很方便的实现异步。
这个技术本质上也是异步非阻塞技术，它是将事件回调进行了包装，让程序员看不到里面的事件循环。程序员就像写阻塞代码一样简单。比如调用 client->recv() 等待接收数据时，就像阻塞代码一样写。实际上是底层库在执行recv时悄悄保存了一个状态，比如代码行数，局部变量的值。然后就跳回到EventLoop中了。什么时候真的数据到来时，它再把刚才保存的代码行数，局部变量值取出来，又开始继续执行。
这就是协程的本质。协程是异步非阻塞的另外一种展现形式。Golang，Erlang，Lua协程都是这个模型。

3.1 同步阻塞
不知道大家看完协程是否感觉得到，实际上协程和同步阻塞是一样的。答案是的。所以协程也叫做用户态进/用户态线程。区别就在于进程/线程是操作系统充当了EventLoop调度，而协程是自己用Epoll进行调度。
协程的优点是它比系统线程开销小，缺点是如果其中一个协程中有密集计算，其他的协程就不运行了。操作系统进程的缺点是开销大，优点是无论代码怎么写，所有进程都可以并发运行。

 
Erlang解决了协程密集计算的问题，它基于自行开发VM，并不执行机器码。即使存在密集计算的场景，VM发现某个协程执行时间过长，也可以进行中止切换。Golang由于是直接执行机器码的，所以无法解决此问题。所以Golang要求用户必须在密集计算的代码中，自行Yield。

实际上同步阻塞程序的性能并不差，它的效率很高，不会浪费资源。当进程发生阻塞后，操作系统会将它挂起，不会分配CPU。直到数据到达才会分配CPU。多进程只是开多了之后副作用太大，因为进程多了互相切换有开销。所以如果一个服务器程序只有1000左右的并发连接，同步阻塞模式是最好的。

3.2 异步回调和协程哪个性能好
协程虽然是用户态调度，实际上还是需要调度的，既然调度就会存在上下文切换。所以协程虽然比操作系统进程性能要好，但总还是有额外消耗的。而异步回调是没有切换开销的，它等同于顺序执行代码。所以异步回调程序的性能是要优于协程模型的。