微服务架构简介（2）— 做好微服务架构面临的挑战

1.3 做好微服务架构面临的挑战

微服务架构并不是一个银弹，它并不能解决世界上所有的架构问题。虽然微服务对很多常见的问题给出了一种解决办法，但是微服务也面临着一些挑战。在转向微服务的过程中，我们经常会遇到分解数据库、API交互、大量的开发和运维工作以及统一团队心态等问题。即便是成功地实现了微服务的主体，也还会面临下面的这样一些挑战。

1.3.1 通过日志调试

对开发人员而言，在微服务架构中调试会变得很艰难。发给应用程序的某一次请求可能会历经多个不同微服务的多次交互才能完成业务处理。每个微服务会产生自己的日志，这种情况下让开发人员来寻找问题的根源简直就是一场噩梦。在分布式日志环境中，调试任何问题都是艰难的。如果我们尝试通过一些合适的工具和脚本把所有服务的日志收集到一个集中的地方，就会需要增加运维团队的工作。

1.3.2 服务监控

单体架构的应用其实很容易监控。在一个单体架构的应用中，只有很少的几个点需要监控，因为所有功能都在一个服务中。一般的监控点包括数据库服务、磁盘空间、CPU使用率以及一些第三方工具等。在微服务架构中，监控这一项的开销会呈指数级增长。微服务架构中的每一个微服务都需要一全套类似单体架构的监控。可以想象一下，几百个微服务凑到一块的时候，报警率会是什么情况。一般而言，为了解决和应对不同服务中产生的报警，我们需要使用一些如Nagios和Monit这样的监控和自愈工具或者脚本。

1.3.3 公共库

在多个服务间共享一个公共库可能不是个好的做法。假设我们有一个A服务，它可以生成一个JSON格式的用户对象，另外有一个B服务会来消费这个JSON对象。这个时候常见的做法是，我们将用户类定义在一个JAR包中，然后在A服务和B服务中均添加该JAR包的依赖。但是这么做的话会引发两个新的问题：首先，使用公共库的方式会将相关的微服务限定在同样一种编程语言中，也就是在一定程度上丧失了微服务的灵活性；另外一个问题是，这种做法增加了服务之间的耦合程度，这也是与微服务的初衷相悖的。我们觉得比较好的做法是在每个服务中分别定义User类，当然你可以说我们违反了避免重复（Don’t Repeat Yourself，DRY）原则。

1.3.4 服务之间的消息传递

在微服务架构中，一个从外部来的请求（来自于前端或者API消费者）可能会引起不同服务之间的多次内部通信，极端情况下会引起网络延迟。这样一来，整个应用程序的性能就会变差。解决这种问题的一般思路是，针对不同的场景选择适用的API间的通信方式。常见的通信接口有同步的REST风格的网络服务接口以及异步的消息队列等。根据不同的业务需要，不同的通信方式可以共存于整个微服务架构中。某些情况下，如果我们需要直接的响应结果，可以采用同步的方式，如HTTP。而如果某个服务只产生中间结果，还需要将此中间结果传递给下一个服务或者很多个其他服务，那么这个时候就比较适合使用消息队列将事件发布到某个主题或者队列中，常见的产有Kafka和SNS。

1.3.5 微服务的部署和版本管理

微服务可以用很多不同的方式进行部署。通常微服务是随着容器（如packer、Docker等）一起发布的。在使用亚马逊云服务（Amazon Web Services，AW S）的时候可以用亚马逊机器镜像（Amazon Machine Image，AMI）来发布，但是AMI创建和部署的时间会比Docker长Docker是一个非常好的用来部署微服务的工具。除了部署之外，微服务架构中，还必须采用一些合适的版本规则，否则整个服务群会因为版本问题变得非常混乱。xx.xx.xx就是一种非常典型的三级式版本格式，最右边一级表示一些小型的漏洞修复或者补丁，中间一级代表了一些新功能的升级，最左边一级则通常对应着一个非常大的改动，例如，整个通信的接口模型都发生变化了，等等。在接下来的章节中我们会详细讨论服务之间通信和部署的相关问题。

原文网址：https://www.epubit.com/book/detail/27566

内容来源：异步社区；版权属【人民邮电出版社 异步社区】所有，转载已获得授权；未经授权，不得以任何方式复制和传播本书内容，如需转载请联系异步社区。