您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(soa是什么)-韵达soa是什么

架构,业务,分布式(soa是什么)-韵达soa是什么

发布时间：2016-12-08加入收藏来源：互联网点击：

1.1 系统架构的演变

随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此在不断的更新。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google 带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安逸得过且过？

其实生活不止眼前的苟且，还有诗和远方。所以我们今天就回顾历史，看一看系统架构演变的历程；把握现在，学习最火的技术架构；展望未来，争取成为一名优秀的Java工程师。

1.1.1 集中式架构

在软件设计中，经常使用的经典的 3 层模型，即表示层、业务逻辑层和数据访问层。

表示层：通常是网页、UI等主要用于和用户交互，也称为交互层。

业务逻辑层：主要是用于处理业务逻辑，例如登录的时候根据用户输入的信息经过业务逻辑层的处理之后才能展现给用户。

数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。

虽然在软件设计中划分了经典的 3 层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

简单来说集中式架构就是一个应用把所有功能都部署在一起。以网上商城为例，如图1-1所示。

图1-1 集中式架构图

优点：

系统开发速度快易于测试、部署适用于并发要求较低的系统

缺点：

代码耦合度高(你调用我，我调用你)，后期维护困难扩展能力受限单点容错率低，并发能力差

很多传统的互联网公司或者创业型公司早期都会使用这样的架构，因为这样的架构足够简单并且能够快速开发和上线。

1.1.2 垂直架构

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分。这种架构就是垂直架构，相比于集中式架构，垂直架构将应用分解成了多个小模块，它们相互独立，互不影响。如图1-2所示。

图1-2 垂直架构图

优点：

可以把单台机器变成多台机器的集群，解决了并发问题可以针对不同模块进行优化方便扩展，容错率提高系统间相互独立，减少业务的耦合度

缺点：

服务之间相互调用，如果某个服务的端口或者ip地址发生改变，系统调用需要手动更改搭建集群之后，实现负载均衡比较复杂

当服务器的负载越来越高，场景越来越复杂集中式架构不能满足我们需求的时候可以选择垂直架构

1.1.3 分布式架构

当垂直应用越来越多，应用之间交互不可避免，这时候我们就需要将核心的业务提取出来作为独立的服务，并逐渐使其形成稳定的服务中心，从而使前端应用能够更快的响市场的需求。如图1-3所示。

图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/5    1 2 3 4 5 下一页 尾页