For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
随着互联网的不断发展,越来越多的软件开发项目都由单体架构开发向微服务架构开发转变,而本文我们就通过案例分析来了解一下,微服务架构优缺点都有哪些。
1、单体架构
就是一个产品(或项目)一个交付物,如果是Java开发的话,通常是一个带有单一入口的WAR/JAR包,所有的业务逻辑全部包含在这个文件里,或许是通过模块化开发后集成,分层设计,终从上到下形成一个不可分割的整体。
单体架构开发模式简单,部署发布也非常简单,这是单体架构比较明显的优势。但是单体应用所有的代码一般都在一个工程里(可以通过微内核+插件的方式进行代码层面的分治管理),随着业务的扩展,时间的推移,代码就会难以管理,后期维护的成本很高。同时,单体应用的弹性扩展的能力较差,而且可用性随着并发的提高也会变差,无法更细粒度的进行弹性扩展。
2、微服务架构
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
3、优点
低耦合
更容易做到高内聚低耦合,因为服务是独立的,从一开始就完全解耦,边界清晰,所以更容易保持各自的模块化实现;
复用
大部分采用微服务架构的公司,一个微服务有一个独立的团队来长期维护,对外提供标准的不同版本的接口,只要其他产品有此类需求,就可以对接,一个微服务,可以在多个产品中复用;
高效
由于服务本身所承担的业务功能的单一,决定它的规模和体积都不会太大,并且有独立的维护团队,使得沟通、项目编译启动的速度、测试、部署CICD都变得会非常高效;
异构性
每一个微服务可以有自己的技术选型,技术实现相互隔离,可以选择更好的满足自身特点的技术,并且老的服务可以更容易的完成自我重构和技术迭代升级;
故障隔离
相对单体架构,这一点更容易做到,故障的影响范围可以缩小到故障服务自身,通常使用熔断、降级等手段,提升整个系统的稳定性
4、缺点
运维要求高
更多的服务意味着要投入更多的运维。
分布式固有的复杂性
使用微服务构建的是分布式系统。对于一个分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的问题。
接口调整成本高
微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有用到这个接口的微服务都需要进行调整。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。