独立开发一个云（PaaS）的核心要素, Go, Go, Go!!!

最近一年的工作，有很大的比重在做云平台的事情，简单来说，就是为公司内用户提供一个PaaS，用户可以在我们的云平台上方便的将单机服务程序扩展为多实例程序，以平台服务化的方式对外提供。在这里简单分享一下。

首先简单说一下我们解决了用户的什么需求，或者说痛点。

基础算法直接以库的形式提供给应用方？

用户提供了一个基础算法，这个算法可能以一个动态库的形式提供，那么使应用方需要关注编译依赖，需要关注词典等模型文件，开发成本比较高。尤其是如果这个基础算法需要升级，或者模型文件需要升级的时候，还需要通知应用方进行修改。而且，如果基础算法不稳定，有出core的行为，那么势必影响了应用方的服务质量。还有就是，如果基础算法非常耗资源，比如CPU，内存占得太多，可能会影响应用方程序对于资源的使用。

基础算法的服务化

为了避免基础算法以动态库提供给应用方的种种弊端，基础算法可以以网络服务的形式提供，这就是基础算法的服务化。就是说，基础算法是一个网络服务，用户直接访问这个网络服务即可。这样，基础算法的服务接口只要不变，不论它如何升级，都不需要应用方做任何修改。开源的Thrift，等等RPC的方案，都很好的满足了基础算法服务化的需求。

服务化的质量如何衡量

那么一个服务化的基础算法，如何保证上面所说的服务质量和延时上的要求呢。尤其是服务质量，或者说可靠性。如果我们假设机器永远无故障，网络设备也永远运行正常，服务也足够稳定，不会有core，也不会升级等等，那么直接找一些机器拉起来就万事大吉了。但是，现实却是残酷了，首先服务可能会有故障，它应该会不断升级（如果有一个不用升级的程序，要么是太完美了，要么就是没有人用了，大家写程序都知道，完美的程序你永远写不出来，少写点烂代码才是正常追求），升级的过程不能影响服务质量，还有服务不可能独占机器的，很有可能会和其他服务混布，那么如何选择合适的机器部署，也是一个问题。还有，很多时候一个服务实例是满足不了需求的，可能要部署多个服务实例，这里边的问题就更多了，请求发给哪个实例，负载均衡，等等等。

服务平台化需要面对的问题

我们下面将服务化的基础算法，以承诺的服务质量对外提供的过程，称为服务的平台化。就是说，服务化的基础算法，经过一个平台对外提供，就能获得相应的服务质量。那么平台化的挑战有哪些呢？

如果一个基础算法自己想实现平台化，闭门造车，需要做很多工作。这也是PaaS存在的意义，将大家服务化的工作都通用化，让策略开发者解放出来。那么，平台化要解决的哪些问题，或者基础算法服务化的痛点在哪里呢？