🧑💻作者:大二计算机学生
🏠主页:关注学习更多技术
📌关键:微服务
软件开发
架构
概念
大家好,今天分享的是企业香饽饽的架构,微服务架构,读完本文,相信你会对微服务的概念清晰很多,我是小周,如果觉得文章写的不错,记得三联支持可怜的博主呀
直接讲微服务架构是什么,难免太过生硬,任何新技术诞生多多少少都是有原因的,那么在聊微服务架构之前,我想应该先从单体架构的概念以及优缺点说起。
说到单体架构,我接触最多就是MVC
架构,优点是学习成本低,上手快,测试、部署、运维也比较方便,甚至一个人就可以完成一个小型网站的开发与部署。
以MVC
架构为例,业务通常是通过部署一个(圈重点)WAR包到Tomcat服务器,启动Tomcat
监听某个端口即可对外提供服务,早期在业务规模不大、团队规模较小的时候,单体架构是很不错的选择。
然而随着业务规模的不断扩大,团队人员的不断增加,单体架构就会开始出现一些问题。比如团队协作成本变高,一旦业务出问题,几乎所有相关开发人员都要参与其中解决,效率低下,成本高,系统的可用性变差,因为所有业务都打包在一块并部署,一旦某一个功能所涉及的代码或者资源出现问题,就会影响整个WAR
包中部署的功能,是十分严重的。部署效率低下,单体应用代码越来越多,依赖也不断增加,应用部署测试的时间都够我打一把逆风王者了。业务增长,服务启动的时间就会变长,上线速度让人头疼……
因此,急需一种新的架构能将应用的不同模块解耦合,降低开发部署维护成本,服务化的思想也就应运而生了,微服务,能大力提高应用交付的效率!
简单说,服务化就是把传统的单体应用中通过JAR
包依赖产生的本地方法调用,改造成通过HTTP
的REST API
远程接口调用。
看得出来,通过服务化,可以改善单体应用膨胀,系统耦合度高,协作效率低下等问题。
得益于以 Docker
为代表的容器化技术的成熟以及 DevOps
文化的兴起,服务化的思想进一步进化为今天我们熟知的微服务架构。
DevOps 是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例,通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
那么微服务有什么特点呢?
由此可见,微服务化给服务的发布和部署,以及服务的维护带来了诸多好处。
微服务架构是一种系统架构风格和思想,现实中想要搭建一套微服务系统,则需要微服务框架的支持。随着微服务的流行,很多编程语言相继推出了自己的微服务框架,比如:
Spring Cloud
:基于 REST 服务来构建服务,帮助架构师构建出一套完整的微服务技术生态链
Spark
:最好的 Java 微服务框架之一,该框架支持通过 Java 8 和 Kotlin 创建微服务架构的应用程序
Dubbo
:由阿里巴巴开源的分布式服务框架
……
Go
语言中的微服务框架较少,使用的较多的是 GoMicro
,它是一个 RPC 框架,具有负载均衡、服务发现、同步通信、异步通讯和消息编码等功能
Phyton
中的微服务框架主要有 Flask、Falcon、Bottle、Nameko 和 CherryPy 等
还有很多语言,都有自己的微服务框架,这里就不一一列举了,博主熟悉的就是 Spring Cloud
服务是由单体架构应用进化到服务化拆分开发部署,后期随着移动互联网规模的不断扩大,敏捷开发
、持续交付
、DevOps
文化的发展和实践,以及基于Docker
容器化技术的不断成熟,将服务细化,微服务架构开始流行,逐渐成为应用架构的未来演进方向。
简单概括,微服务架构是将复杂庞大的单体应用进行细粒度的服务化拆分,每个拆分出来的服务交给小团队进行开发和运维,完成后各自独立打包部署,从而极大地提高了应用交付的效率以及维护迭代的难度,所以逐步被各大互联网公司所普遍采用。
读到这里,想必你对微服务有了基础的认识,作者能力有限,如果文章写的有差错,还请指出纠正,最后,希望你能打好基础,脚踏实地,加油吧少年,别忘了三联支持可怜的博主呀,我是小周,期待你的关注。