十万个为何之SOA服务,服务治理,微服务

SOA与服务治理

SOA:  面向服务的体系结构 (SOA) 是一项引人注目的技术，用于开发与业务模型保持最佳一致性的软件应用程序。

服务治理:  也称为SOA治理，指的是用来管理SOA的采用和实现的过程。

SOA（面向服务的体系结构）概念由来已久，在10多年前便开始进入到咱们广大软件开发者的视线中。SOA是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。SOA能够看做是B/S模型、Web Service技术以后的天然延伸。

服务治理要点

• 服务定义(服务的范围,接口和边界)
• 服务部署生命周期(各个生命周期阶段)
• 服务版本治理(包括兼容性)
• 服务迁移(启用和退役)
• 服务注册中心(依赖关系)
• 服务消息模型(规范数据模型)
• 服务监视(进行问题肯定)
• 服务全部权(企业组织)
• 服务测试(重复测试)
• 服务安全(包括可接受的保护范围)

SOA服务落地 (dubbo的实践使用)

直到2011年10月27日，阿里巴巴开源了本身的SOA服务化治理方案的核心框架Dubbo，服务治理和SOA的设计理念开始逐渐在国内软件行业中落地，并被普遍应用。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可经过高性能RPC实现服务的输出和输入功能，和Spring框架能够无缝集成。

做为一个分布式服务框架,以及SOA治理方案,Dubbo主要包括

• 高性能NIO通信及多协议集成
• 服务动态寻址与路由
• 软负载均衡与容错
• 依赖分析与服务降级

Dubbo的最大特色是按照分层的方式来架构,使用这种方式可使各个层之间解耦合(或者最大限度的松耦合),从服务模型的角度来看,Dubbo采用的是一种很是简单的模型,要么是提供方提供服务,要么是消费方消费服务,因此基于这一点能够抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.

Dubbo包含远程通信,集群容错和自动发现三个核心部分,提供透明化的远程方法调用,实现像调用本地方法同样调用远程方法,只需简单配置,没有任何API侵入,同事具有软负载均衡及容错机制,可在内网代替F5等硬件负载均衡器,下降成本,减小单点,能够实现服务自动注册与发现,再也不须要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,而且可以平滑添加或删除服务提供者

什么是微服务

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每一个微服务仅关注于完成一件任务并很好地完成该任务。在全部状况下，每一个任务表明着一个小的业务能力。 如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登陆等。此外，它们是彻底独立的，也就是说它们能够写入不一样的编程语言并使用不一样的数据库。集中式服务管理几乎不存在，微服务使用轻量级HTTP、REST或Thrift API进行通讯。 

SOA vs. MicroServices

下面进一步解释上表所述的不一样之处：

• 开发方面 - 在这两种体系结构中，可使用不一样的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发能够在多个团队中组织，可是在SOA中，每一个团队都须要了解常见的通讯机制。另外一方面，使用微服务，服务能够独立于其余服务运行和部署。所以，频繁部署新版本的微服务或独立扩展服务会更容易。您能够在这里进一步阅读有关微服务的这些好处。
• “上下文边界” - SOA鼓励组件的共享，而微服务尝试经过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。因为SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。
• 通讯 - 在SOA中，ESB可能成为影响整个系统的单一故障点。因为每一个服务都经过ESB进行通讯，若是其中一个服务变慢，可能会阻塞ESB并请求该服务。另外一方面，微服务在容错方面要好得多。例如，若是一个微服务存在内存错误，那么只有该微服务会受到影响。全部其余微服务将继续按期处理请求。
• 互操做性 - SOA经过消息中间件组件促进了多种异构协议的使用。微服务试图经过减小集成选择的数量来简化架构模式。所以，若是您想要在异构环境中使用不一样协议来集成多个系统，则须要考虑SOA。若是您的全部服务均可以经过相同的远程访问协议访问，那么微服务对您来讲是一个更好的选择。
• 大小Size - 最后一点但并不是最不重要的一点，SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务每每要小得多。微服务中的服务组件一般有一个单一的目的，他们作得很好。另外一方面，在SOA服务中通​​常包含更多的业务功能，而且一般将它们实现为完整的子系统。 

简单结论: 由于它们服务于不一样的目的，微服务和SOA确实是不一样类型的体系结构。SOA更适合大型复杂企业应用程序环境,微服务架构,更适合于较小和良好的分割,基于Web的系统,正在开发移动或Web应用程序，那么微服务做为开发人员能够为您提供更大的控制权。 

以上部分摘抄至: https://blog.csdn.net/chszs/article/details/78515231

微服务落地(SpringCloud的实践使用)

Spring Cloud 基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

Spring Boot 是 Spring 的一套快速配置脚手架，使用默认大于配置的理念，用于快速开发单个微服务。

重点：

• 基于 Spring Boot
• 云服务、分布式框架集合（众多）

核心功能：

• 分布式/版本化配置
• 服务注册和发现
• 路由
• 服务和服务之间的调用
• 负载均衡
• 断路器
• 分布式消息传递

 

Dubbo 和 Spring Cloud 比较

使用 Dubbo 构建的微服务架构就像组装电脑，各环节咱们的选择自由度很高，可是最终结果颇有可能由于一条内存质量不行就点不亮了，老是让人不怎么放心，可是若是你是一名高手，那这些都不是问题；而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，作了大量的兼容性测试，保证了机器拥有更高的稳定性，可是若是要在使用非原装组件外的东西，就须要对其基础有足够的了解。

以上部分摘抄至: https://www.cnblogs.com/xishuai/archive/2018/04/13/dubbo-and-spring-cloud.html

总结

java知识内容博大精深,以上若是有什么不对的,或者有特殊看法的,请留言一块儿探讨;