您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识
soa是什么(韵达soa是什么)
架构,业务,分布式soa是什么(韵达soa是什么)
发布时间:2016-12-08加入收藏来源:互联网点击:
很多朋友想了解关于soa的一些资料信息,下面是小编整理的与soa相关的内容分享给大家,一起来看看吧。很多朋友想了解关于架构的一些资料信息,下面是小编整理的与架构相关的内容分享给大家,一起来看看吧。
1.1 系统架构的演变
随着互联网的发展,网站应用规模不断扩大。需求激增带来技术压力。所以系统架构是不断更新的。从单一应用,到垂直拆分,再到分布式服务,再到SOA,再到现在火热的微服务架构,以及Google引领的风起云涌的服务网格。是该乘微服舟远航,还是得过且过,游刃有余?
其实生活不局限于当下,还有诗和远方。所以今天我们将回顾历史,看看系统架构的演变;把握当下,学习最热门的技术架构;展望未来,努力成为一名优秀的Java工程师。
1.1.1 集中式架构
在软件设计中,经常使用经典的3层模型,即表示层、业务逻辑层和数据访问层。
表示层:通常是网页、UI等。主要用于与用户进行交互,也称为交互层。
业务逻辑层:主要用于处理业务逻辑。例如,在登录时,用户输入的信息要经过业务逻辑层的处理才能显示给用户。
数据访问层:用于操作数据库。用户会在表示层产生大量的数据,通过数据访问层读写数据库。
虽然经典的三层模型在软件设计上是有划分的,但是没有业务场景的划分。典型的单个应用就是把业务场景的所有表示层、业务逻辑层、数据访问层放在一个项目中,最后编译、打包、部署到一个服务器上。
简单地说,集中式架构是将所有功能部署在一起的应用程序。以网上商城为例,如图1-1所示。
图1-1 集中式架构图
优点:
系统开发速度快,易于测试,部署适合低并发需求的系统缺点:。
代码耦合度高(你叫我,我叫你),后期维护困难,可扩展性有限,单点容错低,并发性差。很多传统的互联网公司或者创业型公司,前期都会使用这种架构,因为它足够简单,可以快速开发上线。
1.1.2 垂直架构
当访问量逐渐增加,单一应用无法满足需求时,此时为了应对更高的并发和业务需求,我们按照业务功能对系统进行拆分。这种架构是垂直架构。与集中式架构相比,垂直架构将应用分成几个小模块,彼此独立,互不影响。如图1-2所示。
图1-2 垂直架构图
优势:
可以把单机变成多机集群,解决并发问题,方便优化扩展不同模块,提高容错率,使系统相互独立,降低业务耦合度。
服务相互调用。如果服务的端口或ip地址发生变化,需要手动更改系统调用。集群搭建好之后,实现负载均衡就比较复杂了。当服务器的负载越来越高,场景越来越复杂,集中式架构无法满足我们需求的时候,可以选择垂直架构。
1.1.3 分布式架构
当垂直应用越来越多的时候,应用之间的交互是不可避免的。这时候就需要把核心业务提取出来作为一个独立的服务,逐步让它成为一个稳定的服务中心,让前端的应用更快的响应市场需求。如图1-3所示。
pgc-img-caption">图1-3 分布式架构图
优点:
将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率缺点:
系统间耦合度变高,调用关系错综复杂,难以维护1.1.4 SOA
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键
面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA结构如图1-4所示。
图1-4 SOA结构图
优点:
简化系统的开发有更好的适应性和扩展性简化了提供,寻找和使用服务的过程通过共同资源的利用,减少了开支缺点:降低了系统的性能存在太多没有意义的文件信息运维、测试部署困难1.1.5 微服务架构
SOA结构可以在最大程度上避免共享业务的重复建设,资源连接瓶颈等问题。那么被拆分出来的服务是否也需要以业务功能为维度来进行拆分和独立部署,以降低业务的耦合以及提高容错性能呢?
微服务架构就是这样一种解决方案,从名字上来看,微服务就是针对可重用业务服务的更进一步优化,比如用户服务拆分的更细,如用户注册服务,用户鉴权服务等。
图1.1.5
优点:
复杂度可控:因为体积小,复杂度低,开发,维护会更加简单。技术选型更灵活: 因为每一个微服务属于独立的项目,所以可以结合业务特性选择相应的技术栈。独立部署: 由于每个微服务都是一个独立运行的进程,所以可以实现独立部署。缺点:
微服务架构整个应用分散成多个服务,定位故障点非常困难。稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大,并且一个服务故障可能导致整个系统挂掉。事实上,在大访问量的生产场景下,故障总是会出现的。服务数量非常多,部署、管理的工作量很大。开发方面:如何保证各个服务在持续开发的情况下仍然保持协同合作。测试方面:服务拆分后,几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。1.2 微服务架构的介绍
1.2.1 微服务架构带来的挑战
这么多小服务,如何管理他们?这么多小服务,他们之间如何通讯?这么多小服务,客户端怎么访问他们?这么多小服务,一旦出现问题了,应该如何自处理?这么多小服务,一旦出现问题了,应该如何排错?1.2.2 如何实现微服务架构
上面提到的微服务的跳转,为了解决这些问题就必须引入更多的技术,进而使得微服务架构的实现变得非常复杂。
下一篇:返回列表
相关链接 |
||
网友回复(共有 0 条回复) |