Dora-RPC 详细设计分析 前言
段干博明
开始写一些关于他的介绍：
Dora-RPC源于我之前工作的一家公司内的一些经历。
对于我们开发来说使用PHP很少做大型的复杂的软件，因为开始的时候我们会下意识的将项目拆分开。
通过各种各样的API相互调用、以此避免过于庞大的代码维护和跨部门调用。
而我在的公司在创业初期时（模板嵌入代码的风格）一直在快速迭代的项目积累了几年，这导致我们的代码的相互依赖十分严重。
甚至出现一个项目集成三个甚至五个项目服务，这让我度过了一段难忘的时光、学到了大量的知识、随着流量慢慢增长我们也渐渐的认识到很多之前没有接触过的事情。
相信大家都经历过一个伙伴在同项目内一起工作，在底层更改了一个字段的名称造成大量系统不能正常工作的情况。这类修改如果修改人没有充分的“觉悟”是不会通知其他开发人员，而这种事情在PHP环境下做了后并不是马上就能发现的（系统往往会用不存在的字段作为判断条件而导致逻辑工作方向异常（一直False））。
从我们看来这类事情是比较糟糕的，为什么我们不能主动的发现这类问题呢？
不是我们不想主动而是我们需要将一个复杂的问题简化到一个级别后才好管理，这需要一个过程和切入点将我们一团乱麻的项目切片。
现实中前后端的复杂度都是不同的，我这里指的前端是指业务集成前端（不是JS前端）。
在服务化的情况下我们可以很快的利用原有的服务能力拼装出各种丰富多样的界面和服务。
而通过服务化恰好的能够将后端的分布式复杂性和并发性与前端业务的组合复杂度完全的隔离开。
最好的效果就是即使后端底层把一个数据库替换了、挂了、在接口上层也不会感受到有任何变化服务依旧稳定完整运行。通过这个方式我们还可以对我们的服务进行管理：完善、性能测试、对接口变更及依赖进行监控等以此来提高我们对外服务的稳定性，也可以加强我们对自己服务的把控。
为什么说后端是复杂的，究其原因是我们的后端服务为了一致性造成他的成本是十分昂贵的。这不仅仅是硬件的投入，还有大量的人力消耗。
在互联网初期建设的时候后端的压力承受能力有限、设备及服务昂贵，如我们的Mysql为了提高它的查询QPS我们做了大量的主从横向纵向表拆分的工作虽然我们人工用大量的技巧解决了这个问题但是实际上消耗还是很庞大的，而没有人能够完全脱离业务做出一个通用的公用的可随时根据流量扩展的数据服务。
后来我们有了很多分布式的数据处理服务，虽然现代的后端比之前幸福了很多、当然这并不意味着后端的数据和缓存是简单的容易的。
我的经历让我发现我们的PHP开发人员大规模的注意力都在“业务实施”上，很少有PHPER关注一些更底层的事宜，我之前也是其中的一员直到有一天我去了微博，为此学到了大量之前没有想到的方式，也借此平台开始做了一些更有意思的事情（此事稍后再提）。
尽管如此回望Dora-RPC实现的方式，还是行业内很超前的先进的、所以才有了进一步介绍这个框架的思想的文章。考虑到很多人没有经历过我的经历我会说很多相关的一些经历细节、有些繁琐、见谅。
重提一个我之前老说的问题：PV 100w的网站和PV 20亿的网站区别是很大的，区别主要体现在服务化和自动化管理以及后端是分布式可扩展的。
而我对于后端只是加一些缓存来减轻后端数据服务压力的网站而没有完善的服务治理的互联网公司只能对其评价是初级阶段。
在我经历过程中我们公司的CTO提过一个过程、我认为他说的很对：任何网站不仅仅要忙于自己业务，如果条件允许还要实现、服务化、自动化、平台化。
当然不是说做了这些我们就会很强大完美、事实上这些服务都是基础支撑而目前很多云服务公司提供了类似的基础服务（只不过很基础的没有太深层次）、有了这些系统后我们内部的灵活性会更强。当然如果做的很糟糕……很复杂……往往是个累赘。
分布式后端服务对于Java来说不是很新鲜的东西，因为Java本身就是一个很复杂工程化的语言，为此他是最早提出消息中间件、微服务、分布式、一致性概念的行业设计、对于大流量、大数据、高并发处理提供了大量开源。
PHP到最近一年才刚刚起步研究这些原因就是大家都在忙着业务套现（笑），由于PHP业务实施的快有些人很快的发了一笔后消失在我们这个行业（或者公司倒闭了、继续笑）而开发人员业务成功后不会再继续关注之前做过的东西。从而导致更大流量的时候PHP扛不住了（业务已经很复杂了，很难整理完善底层了）最后被某些本来就是后端语言摘了桃子。
目前为止我看到大量的语法糖一样的PHP框架、对于性能的优化和企业级别的架构支撑并不是很理想、最起码没有提供很多分布式及服务化的东西（Zend、symfony2、laravel等已经开始向这个方向了），不过最近一年出来很多虽然规模很小但是很欣慰、当然前提是PHP有这么大的企业赞助并去实施这类事情。因为只有经历过才会知道大流量网站的底层怎么做。
最近一年在Swoole群内讨论很多、在群内也学到很多知识给了我很多启发及思考。
服务化对于大型业务流量大的互联网公司帮助很大，只是我们行业没有系统的介绍解释下什么是服务、为什么这么做，很多朋友对于这里的概念有很多种（微笑）。
诚如我之前提到的经历、实际上我这里做的只是为了隔离开前后端的复杂度，让实现业务的灵活尽量不受后端的限制、让我们的变更更可控等等、这些都是在Java领域的服务治理思想上有体现、当然我不是弘扬Java的优秀我想说我提到这些只是提高我们对于这些知识的系统化概念，要想发展还是要先学明白先人的思想，这样我们可以少走一些弯路（虽然目前来说只是少数人在走，笑）。
从上面看出我们不仅仅是要把一些业务、数据抽象成服务、做了这些只是做了一件事情让我们的业务有了一定隔离、隔离后就完美了么？事实上还有更多事情需要做。
事实上我说到的这些不局限于PHP语言。
Dora-RPC 在实际实行过程中我们碰到了大量的细节，服务器本地端口只有65535个（我们可用的还要减少1000个）、客户端短链接每次都需要重新握手链接，然后用完后要好久才能回收这个端口，并发高的时候端口会不够用，后来我们转成了长链接但如果前端进程数超过了后端服务器的可用端口数也会出现这类问题。
另外，实际使用过程中前端接口被用户调用后往往会访问后端服务多次，如PV 100w前端请求、在后端可能是1000w次请求，对于这类请求放大会导致我们的后端服务器要比前端服务多很多，一般小公司如果服务器不多我们还是不能做这类事情的。
这时我们会产生一个疑问：所有服务 都做成API对外服务就好了？这不一定，因为如果访问特别频繁的话我们要做一些精简、合并如数据服务一次拿一条改为一次拿多条、我们要减少我们的请求次数，这样就可以了？不、我们一直以来认为接口就是HTTP对外的一次调用、这不完全、且我们也没有人拿缓存、拿搜索引擎当过数据API服务，我想我们要拓展的视野不仅仅在HTTP上。
线程模型、进程模型、协程以及从最近发展来看呈现了很多方式、但是总的来说如果只是写业务逻辑还是使用单线程的方式实现是最好管理调试的、但是这样做的缺点就是很多可以并发的任务串行化了，而实际上也是单线程+单进程的代码最好写最好维护调试。
对于前端业务如果使用大量的多线程来实现对于常规的开发人员来说是一场灾难。当然有人做了更好的优化比如携程、Nodejs方式的evenloop。不过这些方式虽然提高了CPU利用率但是代价就是代码的维护成本提高很多，很多情况我们写代码还是以好维护好修改为目标的。Go的协程、PHP的Yield、Swoole的IO协程、反倒是形成了一道道风景不过它们各有特色。
单线程慢主要原因就是串行化执行代码到IO这些操作时阻塞导致了CPU空闲、Swoole的协程细化到所有IO操作从而实际开发的时候无感，这个方式是最简单的无关注的 但是只能使用它规定的驱动、PHP的协程Yield实现了多个独立的代码块在人工发现有IO等待时调用他然后去做其他的任务、这可以实现一些灵活的调度，但不是所有人都能掌握 实现思路有些复杂。
Go实现了一句话多个并发任务的执行如果分出来的“线程”有阻塞的话仍旧会阻塞等待。NodeJS使用地狱般的回调实现了全异步操作，但是代码如果复杂调试起来让人欲仙欲死。通过以上的分析对比后，总结出最好是单线程写业务、并发任务能很简单的执行而无需关注底层协层细节对于我们来说是更好业务的方式。毕竟我们的职业青春是有限的、越简单越幸福。
今天写到这里，对于高手来说我以上这些都是废话…只是给大家加深要解决的问题的点的印象…下一步开始介绍Dora-RPC的一些设计细节和思考。如果有错误欢迎各位指正。
（重整理了下，敲得快连个回车都没有，这次只是加了大量换行）
类似资料：