什么是SOA

关于百度百科的解释

我相信很多人跟我一样看的一脸懵逼。

通俗易懂的解释

SOA不是具体的什么技术，而是一种开发项目的思想，这种思想开发的项目有很多好处，更符合现在的互联网系统快速发展的时代。下面举个栗子

设计：比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。现在我要给用户提供一个注册账号的功能。

不用SOA的设计思想的实现：JavaWeb里面写一个注册账号的功能，安卓app里面写一个注册账号的功能，IOS同样如此。那么这样的实现有没有什么问题呢？比如有一天，我的注册方法需要改动，那是不是三个地方都要改，而且要改的一模一样。当然问题不止这一个。

SOA的设计思想实现：用Java（或者是其他语言皆可）单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述注册操作，然后提供一个借口，其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法来注册。就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。这样有什么好处呢？

1. 扩展方便：一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务。
2. 语言通用：实现这个服务的可以试任何语音，只要提供的接口通用就可以了，比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP，在某些并发很高的服务中使用Ruby。
3. 新人友好：新人进公司的时候他无需了解整个项目的架构是怎样的，比如你进阿里了，你想要熟练整个淘宝的架构你会累死，而这种SOA思想开发的项目由于是服务形式的，比方把你分到购物车组，那你只需要了解购物车的功能就好了。
4. 发版方便：比方说你是淘宝购物车项目组的，你的项目改了一些东西要发版（发布生产），如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能（虽然你很确信没改动到，但万一呢？）不得不对淘宝整体的功能都做一遍测试，累死人，而这种形式的测试只需要测试你的购物车的功能，so easy。退一步说，万一你改的代码有问题测试没测出来，那也是影响购物车的功能，用户下单支付不影响。

说完了好处下面来说说坏处

1. 问题排查不便：比方用户买东西的时候出现了一个报错，很难直接定位到问题出在哪个环节，可能是订单组的代码有问题，也可能是支付组的代码有问题。
2. 沟通不便：如果你们在大公司待过的话就会明白，用户组，订单组，购物车组，支付组等等是分别属于不同的领导管理，出了问题沟通起来很麻烦，甚至你都不知道找谁沟通，也能以前跟你沟通的人后来离职了等等的问题。
3. 性能问题：相对于传统项目的直觉调用，SOA中不管你是使用RPC还是什么HTTP等技术调用，肯定会有性能的损耗，因为网络通信是需要时间的。
4. 关系混乱：当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱。
5. 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战。
6. 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了。

整体而言SOA肯定是利大于弊的，虽然缺点很明显，但是基本都是可以克服的，问题排查不便那就对花点时间差呗，沟通不便就找上级领导多沟通呗，性能问题用内网什么的也能降低到很少，关系乱就可以用服务治理。相对而言好处部分基本上是不可能克服的，比如非SOA项目扩展基本很难，全部的代码丢到一个项目里面类似淘宝这种新人可能看三年五年也看不懂。

什么是服务治理

就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。

总结

实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。

参考：https://www.zhihu.com/question/42061683