PHP成长记（二） —— SOA&RESTful软件架构

     你有没有遇到过，同一个数据库的数据，每次做一个产品都要重新实现一遍同样的功能，每一个产品都要单独写一相同的功能模块（比如登录，获取产品列表等），很多以前写的功能模块到现在都不能复用了，工作几年下来，公司里没有沉淀出可以复用的东西……

     如果你遇到过相似的情况，也许你应该关注一下SOA（Service-Oriented Architecture）—— 面向服务的体系结构，这不是一中具体的技术，只是一个设计思想，他的主要思想就是把服务从项目中分离出来，做成接口的形式供其他项目调用，这样的好处很明显，第一、只要约定好接口形式，任何语言都可以相互调用；第二、最大化的复用功能模块；第三、可以横向和纵向扩展，等等。这时大家可能想起来Web Service来了，它主要机遇基于SOAP通过HTTP协议进行调用，这种形式有很多弊病，比如开发麻烦，要生成一个非常大的WSDL文件，生成的数据格式很复杂，有没有一种既简单又安全的方式呢，当然有了，那就是RESTful（Representational State Transfer）描述了一个架构样式的网络系统，很多公司的API都是通过该形式开发，比如微博API，QQ开放平台，淘宝开发平台等等，那它有什么好处呢，首先它基于HTTP协议，通过即 POST、GET、HEAD、PUT 、DELETE、OPTIONS、TRACE等请求方式处理资源，然后返回通用数据格式，例如XML/JSON等，这样不管是B/S，C/S架构都能很好的支持。下面讲解一下RESTful架构设计。

      首先架构图如下：

需要为每个程序分配一个appKey和一个appSecret， 然后通过URL访问服务，最后服务返回数据（JSON / XML格式）。

   可能遇到的问题：

1、安全性

   当请求端发送请求的时候，服务端要验证合法性，那该如何验证呢，大多数方案都是遵循OAuth（现在普遍都升级的到了OAuth3.0）。下面是我设计一种简单方式，在小应用上可以采用。

       2、请求控制

              接口不能无限制的调用，不然服务会被跑慢，所以需要限制请求，方法很多，可以采用Nginx的limit模块，限制用户的调用频率和最大连接数等。

       3、服务扩展

              首先对于以后服务的升级，需要对接口进行非常好的设计，避免后续改变URL，这里建议多应用设计模式来进行程序设计，而随着服务的访问量不断增加，需要对服务进行框架升级，这个可以参考我的《项目成长记》专题文章。

           SOA架构目前已经很成熟，大家可以多进行研究讨论。