传统软件架构与微服务架构

Posted 2023-04-03 悟道xn

一、软件架构是什么

        软件架构是在软件的内部，经过综合各种因素的考量、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此写作，为用户提供需要的价值。

二、考虑的因素有哪些？

        1、业务需求

        2、成本

        3、技术栈

        4、组织架构

        5、可扩展性

        6、可维护性

三、单体架构

        定义：功能、业务集中在一个发布包里，部署运行在同一个进程中。

四、单体架构的优势

        1、易于开发，很容易理解

        2、易于测试

        3、易于部署

        4、易于水平伸缩

五、单体架构面临的挑战

        1、代码膨胀，难以维护

        2、构建、部署成本大

        3、新人上手困难

        4、创新困难

        5、可扩展性差

六、什么是微服务

       使用一套小服务来开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制互联，并且他们可以通过采用自动化的方式部署。

      微服务特征

        1、单一职责，只把相关的机制放在一起，跟这个业务不在紧密的可以分出去

        2、轻量级通信，与平台无关、语言无关的通信机制，如protobuf

        3、隔离性

        4、有自己独立的数据存储系统

        5、微服务可以由开发人员选择最适合自己的语言（技术多样性）只需要提供相应的api

        微服务诞生背景

        1、互联网行业的快速发展

        2、敏捷开发、精益开发

        3、容器技术的成熟，docker有效解决了微服务数量的庞大。

        微服务的架构图（熟悉微服务）

假定业务场景：

1、一个在线教育网站的部分功能

2、用户可以登录注册、获取用户信息

3、由发送邮件发送短信功能

3、可以查看课程列表

 微服务架构优势

        1、每个服务都是相互独立的，可以根据qps的多少，来启动多少个微服务，扩缩容相对容易、都有自己独立的数据库。

        2、技术栈灵活。每个微服务只需要保证自己的api接口

        3、高效团队，团队需要的非常少。

微服务架构不足

        1、需要对原有的系统进行微服务划分

        2、数据一致性、微服务的数据库不同。

        3、沟通成本，如果api改变，如果想修改就需要别的团队联合修改

微服务间如何通讯

	一对一	一对多
同步	请求响应模式，最常见	-------
异步	通知/请求异步响应	发布订阅/发布异步响应

从通讯协议角度考虑        

1、REST api    在网络中客户端和服务端进行通讯的一种格式

2、RPC   dubbo\\dubbox\\motan\\grpc\\thrift

3、MQ     消息队列

RPC 微服务之间通信大部分都是这种

        如何选择RPC框架？

        1、I/O、线程调度模型（看是否单线程、多线程）

        2、序列化方式（json\\xml 可见）（protobuf 不可见）

        3、多语言支持  （看业务是否跨度高）

        4、服务治理（看是否有服务的监控等，一般有服务治理的框架，可以方便集群部署）

        

SOA架构与微服务的区别异同

SOA架构介绍

按照英文维基百科定义：SOA(Service-Oriented-Architecture)是一种“软件”和“软件架构”的设计模式（或者叫设计原则）。它是基于相互独立的软件片段要将自身的功能通过“服务”提供给其他应用 面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务架构介绍

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题

3.SOA架构特点：

系统集成：站在系统的角度，解决企业系统间的通信问 题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

微服务架构特点：

1.通过服务实现组件化开发者不再需要协调其它服务部署对本服务的影响。
2.按业务能力来划分服务和开发团队开发者可以自由选择开发技术，提供 API 服务
3.去中心化每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
4.基础设施自动化（devops、自动化部署）
Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理。

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理

SOA喜欢重用

SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。

通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务

路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有
复杂的依赖关系。

微服务喜欢重写

通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，
把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，
而是减少客户端和服务间的往来.

SOA的好处：

1、降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。

2、程序之间关系服务简单

3、识别哪些程序有问题（挂掉）

缺点：提示了系统的复杂程度，性能有相应影响。

复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高
①它解决了复杂性的问题。
②这种架构使每个服务都能够由专注于该服务的团队独立开发
③Microservice架构模式使每个微服务都能独立部署。
④Microservice架构模式使每个服务都可以独立调整

缺点：多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，重复工作，性能监控等

结论

我们不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。自我SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说，小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。
而微服务架构，在另一方面，是更适合于较小和良好的分割，基于Web的系统。另外，如果您正在开发移动或Web应用程序，那么微服务作为开发人员可以为您提供更大的控制权。最后，我们可以得出结论，因为它们服务于不同的目的，微服务和SOA确实是不同类型的体系结构。