SOA不是具体的什么技术，而是一种开发项目的思想。举例说明：
设计：比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。现在我要给用户提供一个注册账号的功能。
不用SOA的设计思想的实现：JavaWeb里面写一个注册账号的功能，安卓app里面写一个注册账号的功能，IOS同样如此。那么这样的实现有没有什么问题呢？比如有一天，我的注册方法需要改动，那是不是三个地方都要改，而且要改的一模一样。当然问题不止这一个。
SOA的设计思想实现：用Java（或者是其他语言皆可）单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述注册操作，然后提供一个借口，其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法来注册。就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。这样有什么好处呢？
扩展方便：一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务。
语言通用：实现这个服务的可以试任何语音，只要提供的接口通用就可以了，比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP，在某些并发很高的服务中使用Ruby。
新人友好：新人进公司的时候他无需了解整个项目的架构是怎样的，比如你进阿里了，你想要熟练整个淘宝的架构你会累死，而这种SOA思想开发的项目由于是服务形式的，比方把你分到购物车组，那你只需要了解购物车的功能就好了。
发版方便：比方说你是淘宝购物车项目组的，你的项目改了一些东西要发版（发布生产），如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能（虽然你很确信没改动到，但万一呢？）不得不对淘宝整体的功能都做一遍测试，累死人，而这种形式的测试只需要测试你的购物车的功能，so easy。退一步说，万一你改的代码有问题测试没测出来，那也是影响购物车的功能，用户下单支付不影响。
说完了好处下面来说说坏处
问题排查不便：比方用户买东西的时候出现了一个报错，很难直接定位到问题出在哪个环节，可能是订单组的代码有问题，也可能是支付组的代码有问题。
沟通不便：如果你们在大公司待过的话就会明白，用户组，订单组，购物车组，支付组等等是分别属于不同的领导管理，出了问题沟通起来很麻烦，甚至你都不知道找谁沟通，也能以前跟你沟通的人后来离职了等等的问题。
性能问题：相对于传统项目的直觉调用，SOA中不管你是使用RPC还是什么HTTP等技术调用，肯定会有性能的损耗，因为网络通信是需要时间的。
关系混乱：当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱。
运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战。
数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要
原文链接：https://blog.csdn.net/qq32933432/article/details/87195037