PHP远程调用和RPC框架如何改写为支持长尾关键词的?
- 内容介绍
- 文章标签
- 相关推荐
本文共计1238个文字,预计阅读时间需要5分钟。
目录+前言+模块+分项项目+CURL+RPC+Yar+Thrift+SOAP+JSON-RPC+项目+项目细化+人员需求+文档+日志+前言+一个项目,从开始到版本更新,直至最终版本维护。功能持续增加。
目录
- 前言
- 分模块
- 分项目
- CURL
- RPC
- Yar
- Thrift
- SOAP
- JSON-RPC
- 项目拆分带来的变化
- 项目细化
- 人员需求
- 文档
- 后记
前言
一个项目,从开始到版本更新,一直到最后的版本维护。功能在不断增多,对应的代码量也在不断增加,也就意味着项目变得更不可维护,这时候,我们需要用拆分的方式将一个项目打散,以便开发团队更好的对项目进行维护。
分模块
这个阶段,一般也是项目的初级阶段,由于人手不够,一个服务端的接口项目只有一个开发进行维护,根据开发的习惯,会把项目分成若干个模块进行开发,在一个项目下进行部署。
这样做的缺点在于项目会随着版本更新而变得不可维护。
分项目
随着每个模块功能的不断完善,代码变得更加臃肿。这时候需要对项目进行拆分,比如上面的图,分成用户体系项目、支付体系项目。
CURL
开始大家会采用CURL的方式对外部资源进行访问。
比如某短信平台SDK,比如各大第三方提供的SDK,纠结到源码发现都是直接采用CURL函数的方式进行访问。
优点在于没有环境要求,能直接用。
缺点在于并发访问的资源占用问题。
//新浪微博SDK的host/api/"); $result = $client->api("parameter); ?>
注意的是鸟哥出的东西文档比较少,需要多调试。
Thrift
thrift是一个软件框架,用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎,以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。
远程调用的意义在于,不同的子项目可以用更适合自己的语言来解决,更有效率的实现需求。
同时,对团队的开发来讲,更能提高整体的技术水平。
SOAP
由于用的XML就不多描述了,毕竟还是json用的多。
JSON-RPC
下面是返回值的标准
--> [
{"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
{"foo": "boo"},
{"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"}
]
<-- [
{"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
]
实际上你会发现我们在给客户端提供接口的返回值,就是按照这个标准来做的。
相应的,服务端对服务端的数据接收和返回,也要同样按照这个标准来做。
项目拆分带来的变化
项目细化
一个模块对应一个项目,项目之间通过基于REST的接口标准进行面向资源的数据访问。
人员需求
项目拆分的前提是一个项目不足以满足现有的业务发展要求,也就意味着拆分之后的开发人员数量的扩增。
游击队向正规军编制的跨越!
文档
更多的项目也就意味着更多的接口调用文档,适当的处理文档才能更好的提高团队协作效率。
后记
服务的远程调用在于怎么合理的把一个正在变得不可维护的项目从焦油坑中解救出来,并提高项目整体能承载的业务量,不过,世界上没有银弹。
以上就是PHP远程调用以及RPC框架的详细内容,更多关于PHP远程调用的资料请关注自由互联其它相关文章!
本文共计1238个文字,预计阅读时间需要5分钟。
目录+前言+模块+分项项目+CURL+RPC+Yar+Thrift+SOAP+JSON-RPC+项目+项目细化+人员需求+文档+日志+前言+一个项目,从开始到版本更新,直至最终版本维护。功能持续增加。
目录
- 前言
- 分模块
- 分项目
- CURL
- RPC
- Yar
- Thrift
- SOAP
- JSON-RPC
- 项目拆分带来的变化
- 项目细化
- 人员需求
- 文档
- 后记
前言
一个项目,从开始到版本更新,一直到最后的版本维护。功能在不断增多,对应的代码量也在不断增加,也就意味着项目变得更不可维护,这时候,我们需要用拆分的方式将一个项目打散,以便开发团队更好的对项目进行维护。
分模块
这个阶段,一般也是项目的初级阶段,由于人手不够,一个服务端的接口项目只有一个开发进行维护,根据开发的习惯,会把项目分成若干个模块进行开发,在一个项目下进行部署。
这样做的缺点在于项目会随着版本更新而变得不可维护。
分项目
随着每个模块功能的不断完善,代码变得更加臃肿。这时候需要对项目进行拆分,比如上面的图,分成用户体系项目、支付体系项目。
CURL
开始大家会采用CURL的方式对外部资源进行访问。
比如某短信平台SDK,比如各大第三方提供的SDK,纠结到源码发现都是直接采用CURL函数的方式进行访问。
优点在于没有环境要求,能直接用。
缺点在于并发访问的资源占用问题。
//新浪微博SDK的host/api/"); $result = $client->api("parameter); ?>
注意的是鸟哥出的东西文档比较少,需要多调试。
Thrift
thrift是一个软件框架,用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎,以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。
远程调用的意义在于,不同的子项目可以用更适合自己的语言来解决,更有效率的实现需求。
同时,对团队的开发来讲,更能提高整体的技术水平。
SOAP
由于用的XML就不多描述了,毕竟还是json用的多。
JSON-RPC
下面是返回值的标准
--> [
{"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
{"foo": "boo"},
{"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"}
]
<-- [
{"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
]
实际上你会发现我们在给客户端提供接口的返回值,就是按照这个标准来做的。
相应的,服务端对服务端的数据接收和返回,也要同样按照这个标准来做。
项目拆分带来的变化
项目细化
一个模块对应一个项目,项目之间通过基于REST的接口标准进行面向资源的数据访问。
人员需求
项目拆分的前提是一个项目不足以满足现有的业务发展要求,也就意味着拆分之后的开发人员数量的扩增。
游击队向正规军编制的跨越!
文档
更多的项目也就意味着更多的接口调用文档,适当的处理文档才能更好的提高团队协作效率。
后记
服务的远程调用在于怎么合理的把一个正在变得不可维护的项目从焦油坑中解救出来,并提高项目整体能承载的业务量,不过,世界上没有银弹。
以上就是PHP远程调用以及RPC框架的详细内容,更多关于PHP远程调用的资料请关注自由互联其它相关文章!

