微服务架构的优缺点

优点:
首先,微服务易于开发和维护,因为一个服务只关注一个特定的业务功能,业务清晰,代码量少,同时技术栈不受限制,比如有些服务可以使用redis,有些服务使用mysql,部分服务使用JAVA开发,部分微服务使用Node.js开发,微服务代码独立,数据独立,如果修改应用,可以对单服务进行修改再部署,并且可根据需求,对各个微服务进行突破瓶颈,比如升级CPU,增加内存等
缺点:
分布式事务的问题
提升了运维难度(发版、问题排查、配置管理、监控) -->催生了Jenkins + ELK +Spring Config + Spring Admin + Docker
性能降低,网络延迟,接口调整成本高,微服务之间通过接口进行通信

具体
1.易于开发和维护:一个服务只关注一个特定的业务功能,所以它业务清晰,代码量少。开发和维护单个微服务相当简单。而整个应用是若干个微服务构建而成的,所以整个应用在被维持在一个可控的状态;
2.局部修改易部署:单个应用只要有修改,就得重新部署整个应用,微服务解决了这个问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可;
3.技术栈不受限:在微服务架构中,可以结合业务和团队的特点,合理选用技术栈。例如有些服务可以使用关系型数据库Mysql,有的服务可以使用非关系型数据库redis。甚至可根据需求,部分服务使用JAVA开发,部分微服务使用Node.js开发
4.按需收缩:可根据需求,实现细粒度的扩展。例如,系统中的某个微服务遇到了瓶颈,可以结合微服务的特点,增加内存,升级CPU或增加节点。

代码独立。各自团队负责各自微服务的代码维护,互相不会影响,也不容易造成代码冲突。也包括code review、还有功能测试。下载代码也不需要下载全部的代码。如果共用代码,有的功能没有开发好,有的小功能已经开发好了,已经开发好的功能没法单独上线。除非采用很多分支,拆分上线。
微服务系统间的独立。系统之间相对独立,非核心系统的发版或者异常,不会影响整个系统核心业务的运行。更加敏捷。
数据独立。各自服务负责各自的数据,特别是机密数据不需要开放给无关的人员。
业务切分,降低了单个服务的复杂性,负责某一服务的开发人员,只需要了解自己相关的业务。快速上手,focus在各自的业务上。
人的独立。团队管理更方便。比如招一个人负责商品的服务,则该小伙伴不需要了解支付、优惠券、库存相关的业务场景,只需要清楚商品相关的业务规则就可以了

微服务架构缺点:
分布式事务的问题
https://www.cnblogs.com/mayundalao/p/11798502.html
https://zhuanlan.zhihu.com/p/183753774
提升了运维难度(发版、问题排查、配置管理、监控) -->催生了Jenkins + ELK +Spring Config + Spring Admin + Docker
性能降低,网络延迟。单体架构 函数都是内部调用,微服务的间通过REST、RPC等形式进行交互,通信的时延会受到较大的影响。
分户式固有的复杂性:使用微服务架构的是分布式系统。对于一个分布式系统,系统容错,网络延迟都会带来巨大挑战。
接口调整成本高微服务之间通过接口进行通信

参考:
https://www.jianshu.com/p/ded25894040a
https://blog.csdn.net/dpf373521/article/details/102860444

你可能感兴趣的:(面试复盘,数据库,微服务架构,微服务,优缺点,jenkins)