认识达内从这里开始

随着互联网的不断发展，程序员能够掌握的软件架构方法也在增多，我们在上文中就给大家简单介绍了微服务架构的优势内容等，今天我们就再来了解一下，推广微服务架构也会遇到的问题都有哪些。

架构设计是一门权衡、取舍的艺术，没有银弹，更没有十全十美的架构，微服务架构为我们带来了如：“可扩展性”、“容错性”、“灵活性”等诸多优点。我们收获这些好处的同时，也一定会带来某些弊端与挑战，这些挑战可以从四个方面来说：

1)分布式带来的通信复杂性与不确定性

对于单体应用，要完一个业务操作，我们通过本地方法调用，这些调用都在同一个进程内完成。进程内地的方法调用或类库调用，由平台语言本身来提供，比如JVM通过线程栈，能提供可靠、确定的调用机制，并且时间延长几乎可以忽略不计。而在分布式环境中，要完成一个业务操作，服务之间需要跨进程，跨网络进行相互调用，我们称之为远程方法调用，这两种调用方式有着这本质的区别，进程内调用习以为常的事情，在远程调用时就成了必须要面对的问题，这些问题包括：

服务的调用方(消费者)怎样找到被调用(提供者)方?

如果某个依赖服务挂了(进程死了、网络异常，服务器宕机)怎么办?

服务接口需要暴露在网络上，接口的安全怎么保证?

业务代码分散在各个进程中，那统一处理的代码怎么办(比如异常、日志)?单体中我们有AOP编程

如果服务调用链层级太深，时间延迟怎么办?

对于一个业务bug、或线上问题涉及多个服务调用，怎么快速定位、排查问题?

2)非中心化带来的数据不一致性

微服务的一个重要特征是数据的非中心化存储，各个服务使用自己独立的数据库。这就带来了一个严峻的挑战，就是数据库的一致性问题。在单体系统中，使用单一数据库，程序员只需要关心的核心业务问题，我们用数据库的ACID特性，就能轻易的保证数据的一致性，在代码框架的支持下只需要一个标记就能搞定一个事务处理。但是在分布式数据库中要做到这些，就是个非常棘手的问题，需要我们做很多额外的工作，同样对于像报表查询，统计业务从前一个sql语句能搞定的事情，数据非中心存储后就会非常麻烦。

3)众多服务带来构建、配置、测试、部署的困难性

软件系统终是要经过编译、测试、部署到多个环境进行终验证，后再依次部署到生产环境，同时还要考虑生产环境的回滚策略，这些流程在单体应用中只是规模，体积比较大，但毕竟数量是少数的。我们需要可能只是一些细心与耐心。但系统被拆分成诸多微服务之后，假设有20个，同样的事情，重复的劳动我们需要做20次并且保存每次都不能出错，量变引起质变，当服务超过一定数量，我们要面对的不仅仅是重复劳动的问题。

4)业务解耦带来的微服务拆分困难性

对于单体应用，如果我们的业务设计做的不好，模块化划分不到位，后果可能还没有那么严重，毕竟所有的数据都在一个数据库中，所有的代码也都可以进程内调用，大不了我就加一层来解决，实在不行就加两层(玩笑话)，但是，我们想象一下，如果微服务在业务设计时没有规划好，把不该放一起的放到一起，该放一起的强行拆开，整个微服务就成了一团乱麻，远程调用的开销，服务的治理会是一场灾难。

微服务强调的是基于业务功能构建，业务功能之间要松散耦合，有明确边界。然后，对于一个复杂业务系统，在设计早期要做的这点并非易事。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。