rpc

原文： https://blog.csdn.net/libaineu2004/article/details/80554870 ---------------------------------------------------------- Kiev框架简介 kiev是魅族科技推送平台目前使用的Linux-C++后台开发框架。从2012年立项起，先后由多位魅族资深架构师、资深C++工程师倾力打造，到本文写就的时间为止，已经在推送平台这个千万用户级的大型分布式系统上经历了近5年的考验。如今Kiev在魅族推送平台中，每天为上百个服务完成数百亿次RPC调用。 kiev作为一套完整的开发框架，是专为大型分布式系统后台打造的C++开发框架，由以下几个组件组成： RPC框架(TCP/UDP) FastCGI框架 redis客户端(基于hiredis封装) mysql客户端(基于mysqlclient封装) mongodb客户端 配置中心客户端(Http协议, 基于curl实现) 基于zookeeper的分布式组件(服务发现、负载均衡) 日志模块 状态监控模块 核心模块是一个开源的`CSP并发模型`协程库(libgo) 并发模型 Kiev采用了很先进的CSP开发模型的一个变种(golang就是这种模型)，这一模型是继承自libgo的。

REST是所有Web应用都应该遵守的架构设计指导原则。 Representational State Transfer，翻译是”表现层状态转化”。 面向资源是REST最明显的特征，对于同一个资源的一组不同的操作。资源是服务器上一个可命名的抽象概念，资源是以名词为核心来组织的，首先关注的是名词。REST要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。（7个HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS） 什么是RESTful API？ 符合REST架构设计的API。 总结 符合REST设计标准的API，即RESTful API。REST架构设计，遵循的各项标准和准则，就是HTTP协议的表现，换句话说，HTTP协议就是属于REST架构的设计模式。比如，无状态，请求-响应。。。 参考： 理解本身的REST架构风格 http://www.infoq.com/cn/articles/understanding-restful-style/ 理解RESTful架构 http://www.ruanyifeng.com/blog/2011/09/restful.html Restful API设计指南 http://www.ruanyifeng.com/blog/2014/05/restful_api.html 二

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 关键资源 关键资源总是有限的，也就意味着处理能力也有限，所以当面对大量业务时，为了保障自己能够有序的提供服务最经济的做法就是限制同一时间处理的事务数。比如银行的工作人员，一个工作人员同时只能为一个客户服务，来多了根本处理不了,不光是一种浪费而且有可以造成混乱的局面导致工作人员无法工作。 网络请求漏斗 越上层的服务器处理的事务越轻，应付请求的能力也越强，也就意味着同一请求越上层处理时间越短。为了有效的保护下层服务器，就需要对发送给下层的请求量做限流，在下层服务器可接受的范围内。否则就可能会出现下层服务器资源耗尽而无法正常提供服务的情况。 限流场景 服务端限流 如果在服务端做限流，无论有多少个客户端，总的提供能力是固定的（感谢@ xuanbg提出的评论，指出服务端也可以对客户端做精准的判断，后续我再想想实现方案），所以不会因为客户端数量过多而导致资源不足，因为处理不过来的请求会被阻塞等待获取资源。 缺点 缺点也比较明显，由于服务提供者整体设置了最大限流数，此时所有的客户端共享同一份限流数据，那么有可能导致有的服务能分配到资源有些服务请求分配不到资源导致无法请求的情况。 客户端限流 客户端限流解决上服务端限流提到的问题，它能保证每个客户端都能得到响应。但是从其它方面考虑，必须针对不同的客户端做不同的限流策略：