后台开发杂记

工作近一年，觉得应该记录一些东西来帮助自己提高了。

这一年基本上是业务需求的开发，涉及无非c++服务器、go服务器、python脚本还有mq、mongo和redis的使用。代码方面没有什么特别值得说的地方。所以暂时先拿一些小问题开刀。（补充一句，c++11标准的引入从理论上提高了程序的性能，但是为这门静态语言引入了更多的细节，使得程序员苦不堪言。）

问题1 如何让服务尽可能地分散？

这个问题其实很大，但是为了简单的表达这个问题，我先这么写。

下面是一段很传统的代码：

void GameStart(){
  Init();
  Provoke();
  ReadyAndGo();
  Fight();
  WaitForEnd();
  End();
}

如果所有的服务都在同一台服务器的同一线程中完成，这么写是没有问题的。

可是这将导致线程在每个环节都有等待甚至锁死的风险，而且一旦线程死掉，服务将难以恢复。

所以现在重新来描述这个问题：

  如何让众多前后相关联的操作去状态化，使之能够分散到多台服务器上，并可靠的处理？

这个问题基本的基本解决思路就是利用消息队列异步操作。

例如将上面的程序改成下面的形式：

GameStart(){
  Init();
  PushEvent1();
}

onEvent1(){
  Provoke();
  PushEvent2();
}

onEvent2 ...

当然，这只是一个基本的现象，只是简单的这么想还不足以应对企业面临的问题。可以预见的一些问题如下：

• 随着需求复杂化，功能的更新和维护越来越复杂；
• 企业的产品需要更加迅捷的开发、维护；
• 接口应用场景由单一变为多样，且越来越多的接口被公开，开发团队难以维护；
• 服务云端化；

正巧有同事分享了应对这些问题的一种思路——微服务，我也在网上搜索了一些文章，在这里谈谈我的理解。

什么是微服务：

微服务是将系统上特定的逻辑从复杂系统中独立，形成可独立替换和升级的单元，并在系统中以相对统一的形式注册，可以自动化部署并提供服务的小型应用。

微服务带来的重要变化：

• 去中心化，服务不再依赖单一的节点、单一平台、单一的存储，所有功能其所需的环境可以按需配置；
• 系统解耦程度提升，所有的部件可以单独变更，问题可以更加精准的定位；
• 服务高可用，系统能够监控并对故障进行自动化的处理。与之相对的，有额外的开发成本；
• 更加扁平化的系统化和更加明确的开发团队职责。
• （猿老们点猿多多益善，程序猿的流动性越来越高）

在本人看来，http接口是微服务思想最好的实践之一。

参考文章

解析微服务架构(一)：什么是微服务

如何赚得7W月薪，安家北京（无意中进入视野的广告，译者竟然和下面那个文章的作者是一个人，看来此人是很社会了）

因为上面文章中提到了RESTful风格，所以下面顺着这个坑往下跳。

在讨论RESTful前，先谈谈我在后台开发认知的转变过程：

在刚刚接触c++的时候，我有这样的感觉：

c++是一种很牛X的语言，因为类化的对象，很多繁琐的事务都可以通过继承和多态来完成。他很好的解决了封装的问题。

但是随着实践，我发现了这样的弊病：

c++是一门静态语言，他的继承和派生对于小型开发团队很好用，但是限于它是直接对机器语言进行汇编的，很难避免闭门造车的问题。除非你的团队技术足以支撑一套完备的异构通信系统，并且有足够量的开发者接受了这个系统。

教材里面经典的解决方案是使用动态链接库，从而完成模块化开发。但是在互联网时代看来，那就是单机年代的遗物，没有后续发展的空间。相比之下，linux把所有io视为文件的做法是一种理想的开发规范。这时我已经朦胧有了类似于REST的想法。

后来我学习了几种脚本语言，他们给我的感觉是为了完成目标存在，从此我不再关心良好的对象设计能节约多少空间，也不再需要处理大量繁琐的细节，开发效率一刀999级。

可是这样糟糕的效率造成了服务必须是基于集群的，服务通信越来越复杂的问题。这时我又通过学习spark，了解到了一个庞大的云计算系统，并用python实现了一个简单的云平台应用。但这些是专用的，对于其他开发者并没可用性。

就在这探索的过程中，我重新发现了http。因为spark中很多的资源可以通过http接口访问。

那么问题来了，为什么我从c++的学习变成了要谈osi中会话\表示层的协议？

这一切的原因只有一个——量大。

系统的变大一开始只是代码量，随之而来的有开发人员的增加和运行环境的扩大。为了完成系统功能的高可用，需要在不同实现之间建立易于使用的通信规范。换句话说，就是开发者需要简单的使用别的开发者的成果。

以上的经历，将我带向了接下来的主角RESTful架构。

理解RESTful架构（原作者： 阮一峰）

下面将结合原文的内容，进行简单介绍。

越来越多的人在考虑如何开发在互联网环境中使用的软件。

而RESTful架构，就是目前最流行的一种互联网软件架构。Fielding将他对互联网软件的架构原则，定名为REST，即Representational State Transfer。

博主提到Fielding作为HTTP协议的主要作者、Apache服务器软件的主要作者之一，发表过一片论文，旨在设计一种以网络为基础的，功能强、性能好、社会（社会社会的那个社会）的框架。

这个框架（RESTful架构）具有下面的特点：

　　（1）每一个URI代表一种资源；

　　（2）客户端和服务器之间，传递这种资源的某种表现层；

　　（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

当然，这些都是2000年的观点，在当时自然是具有相当代表性的。在今天看就好比在vpn技术成熟以后再去看ipv4的安全性，根本就没有什么可比性，所以我想也没人会说他想的太简单了。

按百度百科来说，当 REST 架构的约束条件作为一个整体应用时，将生成一个可以扩展到大量客户端的应用程序。它还降低了客户端和服务器之间的交互延迟。统一界面简化了整个系统架构，改进了子系统之间交互的可见性。REST 简化了客户端和服务器的实现。

然而这些并没有毛用，因为任何一家有规模的公司都会有类似的规范，我们只要遵守就好了  (╯‵□′)╯︵┻━┻