咱们今天继续说说分布式系统的那些事。
我们现在动不动就讲分布式吧？那么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
关于分布式，我们离不开的一个协调中间件就是zookeeper，我也在慕课网上做了套实战课程，其中也包含了dubbo微服务入门，有兴趣的朋友也可以关注一波:
链接描述