分布式系统的那些事儿（六） - SOA架构体系

有十来天没发文了，实在抱歉！最近忙着录视频，同时也做了个开源的后台管理系统LeeCX，目前比较简单，但是后续会把各类技术完善。具体可以点击“原文链接”。

那么今天继续说分布式系统的那些事。

我们现在动不动就讲分布式吧？那么SOA是不是必须得聊一聊呢？

面向服务的架构，简称SOA，他是基于服务组件的，把原来那种一个大型应用程序的不同的功能拆分为一些接口，通过这些接口串联起来。

这么做的好处是：

1、重用性大大提高

2、明确了接口的服务定义规则

3、定义了自家公司的api标准

4、降低系统耦合性

5、无状态HTTP

SOA不是技术也不是什么标准，他是一个架构，每个公司对SOA的架构体系都不同，有简单的也有复杂的，更有超越荣耀王者那边的微服务存在。

曾经的SOA，我也参与过，那些接口设计十分复杂，用的是SOAP，数据传输通过xml来封装的，虽然那个时候我还是个新手，但是我坚信这样的不人性化的玩意迟早要被替代，如今restful风格的架构已经完全替代之。

现如今不论是SOA还是微服务。我们都会利用restful风格来做，甚至我们还会定义自己的一套标准规范，强制开发人员定义的所有api接口必须走这样的规范，这么做的好处是可以让前后端分离，开发人员可以只专注自己的接口或者对接工作即可。

跟过时的SOAP相比，restful简直就是简介明了的实现方案。所有的服务都是松耦合，可以为第三方提供各式各样的接口。传播行为也十分轻量级。

restful的设计规范：

1、使用URL来同一表示我们的资源路径，这个URL应该一目了然，让人知道调用这个接口地址就能够做什么事

2、接口的同一定义：

对于增删改查CRUD就有了十分明确的定义，request的请求方式有4种，

POST用于定义create操作；

GET用于定义查询操作；

PUT用于定义修改操作；

DELETE用于定义删除操作；

此外执行的那个业务方法名（action或者controller），必须定义为名字意义（对于这个我个人觉得没必要，各自根据自己公司的业务定义即可，官方的规范很难以执行，而且命名会很纠结）

3、无状态性：

普通的web应用我们都是用的session来管理用户会话，但是restful的SOA中，我们必须得使用无状态会话，sessionless，比如利用redis来实现，或者spring-session

4、返回客户端的状态：

我们得定义浏览器的状态，就像404或者500那样，出错了得有一个状态值，最常用的就是200状态，然后就是501、502、503……这样定义下去，而这个状态需要封装在你的一个json实体中让对方获取后进行解析，不论是ajax或者restful，都可以获得这样的json字符串再转换为想要的pojo