微服务架构的优缺点

优点：
首先，微服务易于开发和维护，因为一个服务只关注一个特定的业务功能，业务清晰，代码量少，同时技术栈不受限制，比如有些服务可以使用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