什么是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

### SOA 架构的概念与原理 #### 什么是SOA架构? SOA(Service-Oriented Architecture,面向服务的架构)是一种软件设计和软件架构模式,旨在将软件系统分解为一组松散耦合的服务[^1]。这些服务可以通过网络协议进行调用,从而实现跨平台、跨技术栈的应用集成。 #### SOA的核心概念 在SOA中,“服务”是最基本的单元,它是自包含的功能模块,能够独立执行特定的任务并返回结果[^2]。以下是几个重要的核心概念: - **服务(Service)**:提供了一组功能接口,供其他应用程序或组件调用。 - **服务注册表(Service Registry)**:作为集中式的元数据存储库,用于记录可用服务及其描述信息,帮助客户端查找所需的服务[^3]。 - **企业服务总线(Enterprise Service Bus, ESB)**:充当中介角色,在不同服务之间传递消息,并处理通信细节,如转换协议、路由请求等。 #### 工作原理 SOA的工作流程通常涉及以下几个阶段: 1. **服务发布**:服务提供商将自己的服务能力登记到服务注册表中; 2. **服务发现**:潜在的服务使用者查询服务注册表来定位满足需求的服务实例; 3. **绑定和服务调用**:一旦找到合适的目标服务,则建立连接关系并通过标准化的消息格式发起远程过程调用(RPC)。 此外,随着汽车行业向更高级别的自动驾驶迈进,EE架构也经历了显著变化——从最初的分布式ECU控制逐步演变为基于域控制器甚至中央计算机为中心的新一代体系结构。这种转变带来了新的挑战,比如缩短开发周期的同时还要兼顾性能优化等问题;因此采用合适的框架和技术手段显得尤为重要[^4]。 ```python class ServiceRegistry: def __init__(self): self.services = {} def register_service(self, name, endpoint): """Register a new service.""" if name not in self.services: self.services[name] = endpoint def find_service(self, name): """Find the registered service by its name.""" return self.services.get(name) registry = ServiceRegistry() registry.register_service('weather', 'http://api.weather.com') print(registry.find_service('weather')) ``` 上述代码片段展示了一个简单的`ServiceRegistry`类模拟了服务注册的过程。 ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值