微服务之springcloud

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

微服务的发展 简介

俗话说,没有最好的架构,只有最合适的架构。微服务架构也是随着信息产业的发展而 通常来说,我们认为架构发展历史经历了这样一个 过程:单体架构-> SOA 面向服务架构-> 微服务架构。

1:单体架

在还是学生的年代,我们创建的绝大部分应用都属于单体应用。那个时候,我们会把数据库连接、业务逻辑处理、展示 逻辑等放在一起处理。即使我们学习了MVC架构以及由此衍生出来各种多层架构,但是,此时应用还是一个应用,部署时也是按照一个整体运行。

弊端:

1:系统启动慢:一个进程包含了所有的业务逻辑,涉及到的启动模块过多,导致系统的启动,重启周期长;

2:系统错误隔离性差:可用性差,任何一个模块的错误可能导致整个系统的宕机;

3:可伸缩性差:系统的扩容只能对整个应用扩容,不能做到对整个功能点进行扩容;

4:线上问题修复时间长:任何一个线上问题修复需要对整个应用系统进行全面升级;

微服务之springcloud

2:SOA 架构

面向服务的体系结构(Service-Oriented Architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。

微服务之springcloud

弊端:

1:高门槛:ESB 本身就是一套非常复杂的系统,通过ESB 落地SOA ,对开发人员 的要求很高。甚至还会需要厂商参与;

2:厂商绑定:由于缺乏统一保准,不同厂商的解决方案之间很难做切换。

3:不适应云环境:在如今的互联网时代,速度就是一切。由此诞生了敏捷开发、持续集成等在不同节点提升业务上线速度的办法。但是方向是不一致的。

4:中心化:虽然应用本身实现了分布式与水平扩展,但是ESB 却成了系统的中枢神经。

3:微服务架构

简单的来说微服务架构的核心目标是把复杂问题简单化,通过服务划分,把一个完整的系统拆分成多个高内聚、低耦合的小的子系统。使每个子系统可以独立的运行、升级和测试。然后再通过一些集成手段将这些子系统组合在一起,对外提供完整功能的过程。说到微服务不得不提到springcloud。

Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等组件,都可以用 Spring Boot 的开发风格做到一键启动和部署。将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来,通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

微服务之springcloud

优点

1:易于开发和维护: 一个服务只关注一个特定的业务模块,所以它业务清晰,代码量少。开发和维护单个微服务相当简单。开发简单、开发效率高,一个服务可能就是专一的只干一件事。

2:单个服务启动快: 单个服务代码量少,所以启动快。

3:局部修改易部署: 单个应用只要有修改,就得重新部署整个应用,微服务解决了这个问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。

4:技术栈不受限: 在微服务架构中,可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库Mysql,有的服务可以使用非关系型数据库redis。甚至可根据需求,部分服务使用JAVA开发,部分微服务使用Node.js开发。

5:按需收缩: 可根据需求,实现细粒度的扩展。例如,系统中的某个微服务遇到了瓶颈,可以结合微服务的特点,增加内存,升级CPU或增加节点。

结语

下篇文章从服务化架构演进的角度来看看为什么 Spring Cloud 更适应微服务架构

微服务之springcloud

原文始发于微信公众号(coding途中):微服务之springcloud