一、服务架构设计与发展

1、单体架构

微服务入门介绍

单体架构的特点和好处:

  • 单一代码库、IDE友好、看着简单
  • 容易部署
  • 开发模型简单,一份代码库进行编码、构建和部署
  • 技术栈单一

单体架构的问题:

  • 庞大的代码库,关系错综复杂。
  • 交付周期长。
  • 扩展能力与弹性受限。
  • 新技术与工具框架使用会受限。
  • 维护成本高。

2、服务化架构:

微服务入门介绍

服务化架构的特点和好处:

  • 对业务进行分层,通常分为表现层(前段)、公共服务、业务逻辑服务、数据访问层等。
  • 对业务进行解耦,通过Pub-Sub或RPC进行服务器间调用关系解耦。
  • 服务独立性,多数服务可以进行独立打包发布。
  • 每个服务的技术栈单一。
  • 部署简单,具有可伸展性。

服务化架构的问题:

  • 对于部分服务而言,代码库依然很强大。
  • 打包,发布和部署流程不足够好。
  • 维护团队间沟通受阻,技术经验有效传递不够。
  • 服务增多对开发人员不够友好。

3、微服务架构:

微服务入门介绍

     服务注册——>服务发现——>服务调用

4、架构设计发展:MVC Services(视图、业务逻辑前后端分离)——>SOA(大型系统分层解耦,标准接口调用,分布式系统)——>Micro(云计算产物,关注敏捷交互和部署速度、频次)

二、微服务简介

  • suite of small service:由一系列小服务组成。
  • running in its own process:每个服务运行于自己的进程。
  • built around business capabilities:围绕着业务功能进行建模。
  • independently deployable:每个服务可进行独立部署。
  • bare minimum of centralized managerment:最低限度集中管理。

1、微服务的特征:

  • 每个微服务都是业务完整的:接口及界面呈现、业务逻辑、数据管理。
  • 每个微服务仅仅对一个业务负责:产品服务、评价服务、支付服务、订单服务。
  • 每个微服务接口明确定义:接口消费只关注接口,对微服务不具备依赖。
  • 独立部署、升级和伸缩。

2、微服务的独立性关键词:

  • 代码库独立
  • 技术栈独立
  • 可伸缩性、可扩展性独立
  • 业务功能独立

3、独立的代码库:每个微服务具备自己的代码库

  • 由团队开发者维护
  • 编译、打包、发布及部署都很快
  • 服务启动迅速
  • 在各个服务的代码库间没有交叉依赖

4、技术栈对立:每个微服务都有自己独立的技术栈实现

  • 根据业务实现需求来选择最适合的需求栈
  • 团队可以尝试新的技术、工具和框架
  • 所选的技术一般来说都是轻量级
  • 不需要同一标准化技术栈的选择。无需关注因技术选型而纠结业务的实现

5、独立的可伸缩性:每个微服务都可以独立伸缩

  • 更加直观的定位性能的瓶颈
  • 数据库分片可根据需求来

6、业务功能独立:每个微服务可以在不影响其他微服务的情况下进行功能扩展

  • 例如更新新版本界面或者某个微服务中的某项功能时,无需更新整个系统
  • 可以进行整个业务功能的重写,并替换之

7、微服务的优点:

  • 每个服务足够内聚,足够小,代码容易理解,开发效率高。
  • 服务之间独立部署,微服务架构让持续部署成为可能。
  • 每个服务可以各自进行x扩展和z扩展,而且每个服务可根据自己的需要部署到合适的硬件服务器上。
  • 容易扩大开发团队,可以针对每个服务组件自己的开发团队。
  • 提高容错性(fault isolation),一个服务的内存泄漏,并不会导致整个系统瘫痪。
  • 系统不能被长期限制在某个技术栈。

微服务入门介绍

8、微服务不足:

  • 微服务应用是分布式系统,由此会带来固有的复杂性,开发者需要在RPC或消息传递之间选择并完成进程间通讯机制。此外,他们必须用代码处理消息传递过程中速度过慢或者不可用等局部失效问题。
  • 开发人员需要处理分布式系统的复杂性:开发人员需要设计服务间的通信机制,对于需要多个后端服务的user case,要在没有分布式事物的情况下,实现代码非常困难;设计多个服务直接的自动化测试也具备相当大的挑战。
  • 服务管理的复杂性:在生产环境要管理多个不同的服务实例,这意味着开发团队要统一统筹。(PS:现在docker的出现适合解决这个问题)。

9、应用微服务架构的时机如何把握?

     对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司,不需要考虑微服务架构模式,这时候最重要的是快速开发、快速部署、快速试错

三、微服务架构工作流程

  • 设计阶段:将产品功能拆分成若干个服务,为每个服务设计API接口。
  • 开发阶段:实现API接口(包括单元测试)实现UI原型(界面)。
  • 测试阶段:前后端集成,验证产品功能。
  • 部署阶段:发布测试环境,发布开发环境。

四、Spring Boot介绍

1、为什么使用springBoot?

  • Spring Boot是为简化Spring项目配置而生,使用它使得jar依赖管理以及应用编译和部署更为简单。Spring Boot提供自动化配置,使用Spring Boot,你只需编写必要的代码和配置必须的属性。
  •   使用Spring Boot,只需20行左右的代码即可生成一个基本的Spring Web应用,并且内置了tomcat,构建的fat Jar包通过java -jar就可以直接运行。
  • 如下特性使得Spring Boot非常契合微服务念,可以结合Spring Boot与Spring Cloud和Docker技术来构建微服务并部署到云端:
  • 一个可执行jar即为一个独立服务
  • 很容易加载到容器,每个服务可以在自己的容器(例如docker)中运行
  • 通过一个脚本就可以实现配置与部署,很适合云端部署,并且自动扩展也更容易

2、springBoot有哪些特性?

(1)无需手动管理依赖jar包的版本:
  •  spring-boot-starter-amqp通过spring-rabbit来支持AMQP协议(Advanced Message Queuing Protocol)。
  •  spring-boot-starter-ws支持Spring Web Services。
  •  spring-boot-starter-redis支持Redis键值存储数据库,包括spring-redis。
  •  spring-boot-starter-test  支持常规的测试依赖,包括JUnit、Hamcrest、Mockito以及spring-test模块。

(2)独立运行的Spring项目

       Spring Boot默认将应用打包成一个可执行的jar包文件,构建成功后使用java -jar命令即可运行应用。或者在应用项目的主程序中运行main函数即可,不需要依赖tomcat、jetty等外部的应用服务器。其中内置的servlet Container。此外,你仍然可以部署Spring Boot项目到任何兼容Servlet3.0+的容器。
3、SpringBoot总结:

  • 缺少注册、发现等外围方案
  • 缺少外围监控集成方案
  • 缺少外围安全管理方案
  • 缺少REST落地的URI规划方案

所以SpringBoot只是一个入门级的微框架

相关文章:

  • 2021-09-26
  • 2021-12-25
  • 2021-12-16
  • 2021-04-18
猜你喜欢
  • 2021-03-29
  • 2022-01-10
  • 2021-04-02
相关资源
相似解决方案