终于在今天有点时间了，针对原来在比赛和开发当中用到的开发架构做一下总结。上了研究生后，已经有些日子没有写像点样子的开发应用程序了，这里做一下总结。
在真正的生产环境中的开发中，碰到的技术问题其实不大，如何因地制宜，根据需求选择合适的开发架构，对于后期的程序扩展，程序维护，升级等是一个非常重要的事情。在前一段时间的Dell EMC的比赛中，又让自己碰到了熟悉的开发问题，但还是学到了一些新的东西，这里做一下总结。
Restful架构是基于Http应用层协议的产物，RPC架构是基于TCP传输层协议的产物。RPC架构的吞吐量和执行速度优于Restful。但是没有十全十美的架构，这里做一点浅析，文末给出一点参考博客，详细可以通过阅读相关博客完成理解。
Restful是一种轻量级，跨语言，跨平台的web服务方式，他是一种设计理念，他强调将网络中的一切事物看成资源，对资源的所有的操作方式均定义成“查，插，删，改” 四种方式，向外界暴露API，用来调用，所有的操作都是无状态的。
好了好了，书面语都说完了，这会我们说点大白话吧。我们一句一句分析，轻量级是什么意思? 简单，所以复杂的大型应用不适合该架构。跨语言和跨平台这两个可以一起解释。因为该架构一般是针对web应用的，不同模块之间利用Rest进行通信，是利用网络协议来通信，中间传输对应的json对象。因此不同模块之间实际上是透明的，只需要利用HTTP协议，从发送端发送到接收端，接收端自己能够解析网络传输的内容即可。这种解析功能，目前能够用到的web编程语言都可以实现。对于资源的操作方式只有四种，因此极其简单，他能够根据对应的网络状态信息，对其进行响应即可。API其实也就是一个一个的url。对于该架构，该博客描述的非常清楚，此处给出链接。
RPC架构的全名是远程过程调用。这个东西十分强大，目前已经成为主流开发架构。当时在本科的时候，做的一款大型网络应用就是基于此架构。当时用的是java的DWR框架，现在rpc框架相当多，而且吞吐量巨大，是开发主流。这个玩意，在原来有一个大名鼎鼎的“冲击波病毒”，就是建立在该原理之上。其实我们用起来非常简单，因为整个RPC的原理图如下所示：
其实你从图中可以看出，他主要是四部分组成, Client, ClientStub, Server, Server Stub。当你在客户端调用服务器端程序时，调用的方式和函数名和服务器端的一模一样，这样大大缩短了开发时间和交流成本，只需要在后端给出整个函数名列表和参数列表即可。如何实现这一功能，主要是在ClientStub封装Client的调用需求，然后发送给ServerStub，它进行解析后返回给Server，完成调用实现。这一部分的实现主要是利用软件工程中的动态代理模式，利用代理处理器，根据不同的参数，来分发处理请求。当然这一部分，实际开发中不需要我们实现。我们只需要调用服务器方法即可。关于RPC框架的博客可以参考链接
两种架构各有优劣，需要根据具体的项目需求进行选择。在Restful架构方面，python的flask,go的beego等均提供了简单高效的编程接口。在rpc架构方面，java的DWR等，都是非常成熟的开源框架。
