✅作者简介:大家好,我是Philosophy7?让我们一起共同进步吧!🏆 📃个人主页:Philosophy7的csdn博客
🔥系列专栏: 数据结构与算法
👑哲学语录: 承认自己的无知,乃是开启智慧的大门
💖如果觉得博主的文章还不错的话,请点赞👍+收藏⭐️+留言📝支持一下博>主哦🤞
新事物的产生必将会与旧事物发送冲突,而一个新事物的生命力,就是看有无发展空间,那么微服务架构也不例外。随着互联网技术的发展,传统的应用架构已经无法满足实际需求,微服务架构就随之产生。那么传统应用架构到底有什么问题呢?又如何解决呢?
通常我们使用的传统单体应用架构都是模块化的设计,程序在编写完之后会被打包并部署称一个具体的应用,而应用的格式依赖于相应的应用语言和框架。例如: 某电商项目,Web工程会被打成WAR包的形式部署在Web服务器上,而普通的Java程序则被打成一个Jar包的形式包含在WAR中。
如图,这种是我们常见的开发风格,这样做的好处利于开发和调试,并且容易部署。在客户量不多的情况下,这种架构方式(单体应用架构)完全满足需求,但随着用户量的增加,一台服务器就满足不了,此时我们就会考虑系统的水平扩展,通常我们的解决方案就是增加服务器的数量,并将打包好的应用拷贝到不同的服务器(例如:Tomcat),通过负载均衡器(Apache、Nginx)轻松实现水平扩展。
这种架构的存在的问题如下:
针对传统单体架构的问题,大部分企业通过SOA(Service-Oritend Architecture)
面向服务的架构解决上述问题。SOA的思路就是将应用相近的功能聚合到一起,以服务的形式提供出去,因此SOA架构的应用跨域简单理解为一批服务的组合。
虽然使用SOA解决了传统单体架构中的问题,但多数情况下,SOA中相互独立的服务仍会被部署到同一个Tomcat实例下,和单体应用架构相似,随着业务功能的增多,SOA的服务也会变的复杂。透过现象看本质,单体架构的问题仍没有得到解决。
针对这种问题,微服务架构的架构思想也随之产生,也就是将应用分解为小的、互相连接的微服务。
微服务架构是一种架构风格和架构思想,它倡导我们在传统软件应用架构的基础上,将系统业务按照功能进行更加细粒度的拆分,所拆分的每一个服务都是一个独立的应用,这些应用对外提供公共的API,跨域独立承担对外服务的职责,通过这种思想开发的软件服务实体就是微服务
,而围绕着微服务思想构建的一系列体系结构(开发、测试、部署等)我们将它称之为微服务架构
微服务架构 | SOA |
---|---|
一个系统被拆分成多个服务,细粒度 | 服务由多个子系统组成,粗粒度 |
团队级,自下向上开展实施 | 企业级,自上向下开展实施 |
无集中式总线,松散的服务架构 | 企业服务总线,集中式的服务架构 |
集成方式鸡蛋 | 集成方式复杂 |
服务能够独立部署 | 服务相互依赖,无法独立部署 |
微服务的开发可以选用Spring Boot
架构中服务的注册与发现功能,可选用Spring Cloud Eureka、Apache Zookeeper、Consul(国内停用)、Dubbo等
负载均衡可以使用Spring Cloud Ribbon和Dubbo等
服务容错的技术可以使用豪猪哥(Hystrix) 在SpringCloud的子项目中包含
架构中的API网关服务,使用Spring Cloud Zuul、Spring Reactor、Netty等
可以使用Spring Cloud Config
微服务应用的测试工作一般使用Swagger。Swagger是目前最受欢迎的REST API文档生成工具之一,提供了强大的页面测试功能来调试每个RESTful API
微服务官方建议使用Docker来打包和部署微服务。Docker是一个开源的应用容器引擎,可移植性强、启动速度快,适合轻量级的应用