微服务架构核心20讲_极客时间观后总结_2.微服务的利与弊

微服务的优点

1. 强模块化边界

微服务用每个服务作为模块化，类似于我们之前用的一些工具类，比如我们用Md5，我们直接可以用Md5Utils.md532Upper("");这是我们提前封装好的工具类，而微服务一样，每个微服务团队，只要开发好了接口，部署好，我们可以直接调用里面的接口，方便使用。

2. 可独立部署

微服务可以独立部署，每个微服务开发人员或者开发团队可以各自的模块，不受其他业务方影响，提高开发效率。

3. 技术多样性

微服务是可以独立部署，每个微服务是可以用不同的开发技术，比如A服务擅长java语音，B服务擅长其他语言，各个服务之间是不冲突的，可以高效率的完成项目开发。

微服务的劣势

1. 分布式复杂性

单体项目，由于是整个一个单体项目，每个开发人员都 可以看到整体的项目架构，以及整体项目中单代码，甚至可能清晰的了解其他人的业务，那这样就会很清晰；微服务，由于将系统进行了多个微服务的拆分，开发人员很有可能不清楚其他业务模块，甚至整个系统的工作流程都不清楚。

2. 最终一致性

个人理解，和第一章的问题是相似的，粘过来复用一下：

比如我们A服务中管控整个微服务架构的用户数据。
我们B服务是掌控订单数据，订单数据需要冗余下单用户的用户名昵称等，当A服务中的用户数据变更，B服务中，不会发生变更，这就是一个弊端。当然我们可以通过mq等，发生用户数据变化时，通过消息队列进行数据同步，保证一致性！

3. 运维复杂性

运维人员首先要知道每个微服务中运用到的技术，以及需要一些编译工具等，进行安装，还要考虑服务器的容量，资源规划等有一个深入的了解

4. 测试复杂性

由于每个微服务之间相互配合调用，才形成了整个项目，所以测试人员对微服务之间的测试，需要花很打的精力

问答环节

1. 运维人员对于微服务的部署是很困难的，那通过什么手端可以解决这些弊端？

容器化管理，通过jenkins自动化部署，并编写好每个微服务部署脚本等，实现自动化部署。