Spring Cloud与微服务构建：微服务简介

Spring Cloud与微服务构建：微服务简介

单体架构及其不足

1.单体架构简介

在软件设计中，经常提及和使用经典的3曾模型，即表示层、业务逻辑层和数据访问层。

• 表示层：用于直接和用户交互，也成为交互曾，通常是网页、UI等；
• 业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户；
• 数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作；

虽然在软件设计中划分了经典的3层模型，但是对业务场景没有划分。一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终通过编译、打包，部署在一台服务器上。例如典型的J2EE工程，它是将表示层的JSP、业务逻辑层的Service、Controller和数据访问层的Dao打成war包，部署在Tomcat、Jetty或者其他Servlet容器中运行。经典的单体应用如下图所示：

在一个小型应用的初始阶段，访问量较小，应用只需要一台服务器就能够部署所有的资源，例如将应用程序、数据库、文件资源等部署在同一台服务器上。最典型的就是LAMP系统，即服务器采用Linux系统，开发应用程序的语言为PHP，部署在Apache服务器上，采用MySQL数据库。在应用程序的初始阶段，采用这种架构的性价比是非常高的，开发速度快，开发成本低，只需要一台廉价的服务器。此时的服务器架构如下图所示：

2.单体架构存在的不足

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下3个方面：

• 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需时间成倍增加，业务扩展带来的代价越来越大；
• 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限；
• 测试的难度越来越大，单体应用的业务都在同一个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来一定的影响，导致测试难度增加；

3.单体架构使用服务器集群及存在的不足

随着业务的发展，大多数公司会将单体应用进行集群部署，并增加负载均衡服务器(例如Nginx等)。另外，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加而带来的高并发访问量。此时的系统架构如下如所示：



用负责均衡服务器分发高并发的网络请求，用户的访问被分派到不同的应用服务器，应用服务器的负载不再成为瓶颈，用户量增加时，添加应用服务器即可。通过添加缓存服务器来缓解数据库的数据以及数据库读取数据的压力。大多数的读取操作是由缓存完成的，但是仍然有少数操作是从数据库读取的，例如缓存失效、实时数据等。当有大量的读写操作时，将数据库进行读写分离是一个不错的选择，例如MySQL的主从热备份，通过相关配置可以将主数据流服务器的数据同步到从数据库服务器，实现数据库的读写分离，读写分离能够改善数据库的负载能力。

这种架构有一定的处理高并发的能力，也能应对一定复杂的业务需求，改善了系统的性能。但是依然没有改变系统为单体架构的事实，此时系统存在的不足之处如下：

• 系统仍然为单体应用，大量的业务必然会有大量的代码，代码的可读性和可维护性依然很差；
• 面对海量的用户，数据库将会成为瓶颈，解决方案将使用分布式数据库，也就是将数据库进行分库分表；
• 持续交付能力差，业务越复杂代码越多，修改代码和添加代码所需时间越长，新人熟悉代码的时间长、成本高；

由此可见，在应用初期，单体应用从成本、开发时间和运维等方面都有明显的优势。但是随着业务量和用户量的增加，它所暴露出来的缺点也显而易见。单体架构已经不能满足复杂的业务和海量的用户系统，改变单体架构势在必行。

微服务

一.什么是微服务

"微服务"最初是由Martin Fowler在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍，维基百科上是这样描述的：

Martin Fowler，软件工程师，也是一个软件开发方面的著作者和国际知名演说家，专注于面向对象分析>与设计、统一建模语言、领域建模，以及敏捷软件开发方法，包括极限编程。主要著作有《可重用对象>模型》《重构-改善既有代码的设计》《企业应用架构模式》等；

对于微服务，业界没有一个严格统一的定义，但是作为"微服务"这一名词的发明人，Martin Fowler对于微服务的定义似乎更具有权威性和指导意义。他的理解如下：

简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程>中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，>并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言，以及不同数据存储技>术，以保证最低限度的集中式管理；

以我个人对这段话的理解，总计微服务具有如下特点：

• 按业务划分为一个独立运行的程序，即服务单元；
• 服务之间通过HTTP协议相互通信；
• 自动化部署；
• 可以用不同的编程语言；
• 可以用不同的存储技术；
• 服务集中化管理；
• 微服务是一个分布式系统；

1.微服务单元按业务来划分

微服务的"微"到底需要定义到什么样的程度，这是一个非常难以界定的概念，可以从以下3个方面来界定：一是根据代码量来定义，根据代码的多少来判断程序的大小；二是根据开发时间的长短来判断；三是根据业务的大小来划分。

根据Martin Fowler的定义，微服务的"微"是按照业务来划分的。一个大的业务可以拆分成若干小的业务，一个小的业务又可以拆分成若干更小的业务，业务到底怎么拆分才算合适，这需要开发人员自己去决定。例如微博最常见的功能是微博内容、关注和粉丝，而其中微博内容又有点赞、评论等，如何将微博这个复杂的程序划分为单个的服务，需要开发团队去决定。

按业务划分的微服务单元独立不是，运行在独立的进程中。这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。

传统的软件开发模式通常由UI团队、服务端团队、数据库和运维团队构成，相应地将软件按照职能划分为UI、服务端、数据库和运维等模块。通常这些开发人员各司其职，很少有人跨职能去工作。如果按照业务来划分服务，每个服务都需要独立的UI、服务端、数据库和运维。也就是说，一个小的业务的微服务需要动用一个团队的人去协作，这显然增加了团队与团队之间交流协作的成本。所以产生了跨职能团队，这个团队负责一个服务的所有工作，包括UI、服务端和数据库。当这个团队只有1-2个人的时候，就对开发人员提出了更高的要求。

2.微服务通过HTTP来互相通信

按照业务划分的微服务单元独立部署，并运行在各自的进程中。微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制，更多的时候是使用RESTFUL API。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效，并且这种通信机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务，用Go语言写的服务又可以小费用Ruby写的服务。不同的服务采用不同的语言去实现，不同的平台去部署，它们之间使用HTTP进行通信，如下图所示：



服务与服务之间也可以通过轻量级的消息总线来通信，例如RabbitMQ、Kafaka等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。

服务与服务通信的数据格式一般为JSON、XML，这两种数据格式与语言、平台、通信协议无关。一般来说，JSON格式的数据比XML轻量，并且可读性也比XML要好。另外一种就是用Protobuf进行数据序列化，经过序列化的数据为二进制数据，它比JSON更轻量。用Protobuf序列化的数据为二进制数据，可读性非常差，需要反序列化才能读懂。由于用Protobuf序列化的数据更为轻量，所以Protobuf在通信协议和数据存储上十分受欢迎。

服务与服务之间通过HTTP或消息总线的方式进行通信，这种方式存在弊端，其通信机制是不可靠的，虽然成功率很高，但是还是会有失败的时候。

3.微服务的数据库独立

在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库表的数量越来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。例如一个应用有这样几个业务：用户信息、用户账户、用户购物车、数据报表服务等。典型的单体架构如下图所示：



微服务的一个特点就是按照业务划分服务，服务与服务之间无耦合，就连数据库也是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。这样做的好处在于，随着业务的不管扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用；还有一个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。

另外，随着存储技术的发展，数据库的存储方式数据库的存储方式不再仅仅是关系型数据库，非关系型数据库的应用也非常广泛。例如Redis、MongoDB，它们有着良好的读写性能，因此越来越受欢迎。一个典型的微服务系统，可能每一个服务的数据库都不相同，每个服务所使用的数据存储技术需要根据业务需求来选择，如下图所示：

4.微服务的自动化部署

在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度划分的越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是Docker容器技术的推进，以及自动化部署工具(开源组件Jenkins)的出现，自动化部署变得越来越简单。

自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，部署过程的每一步自动化，提高软件的质量。构建一个自动化部署的系统，虽然在前期需要开发人员或运维人员的学习，但是对于整个软件系统来说是一个全系的概念。在软件系统的整个生命周期中，每一步是由程序控制的，而不是人为控制，软件的质量提高到了一个新的高度。随着DevOps这种全新概念的推进，自动化部署必然会成为微服务部署的一种方式。

5.服务集中化管理

微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如Spring Cloud采用Eureka来注册服务和发现，另外Zookeeper、Consul等都是优秀的服务集中化管理框架。

6.分布式架构

分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完成。

分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。

微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局ID等，而单体系统不需要考虑这些复杂性。

另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是"雪崩效应"。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如"熔断机制"。

7.熔断机制

为了防止"雪崩效应"事件的发生，发呢不是系统采用了熔断机制。在用Spring Cloud构建的微服务系统中，采用了熔断器(即Hytrix组建的Circuit Breaker)去做熔断。

例如在微服务系统中，有a、b、c、d、e、f、g、h等多个服务，用户的请求通过网关后再到具体的服务，服务之间相互依赖，例如服务b依赖于服务f，一个对外暴露的API接口需要服务b和服务f相互协作才能完成。服务之间相互以来的架构如下图所示：



如果此时服务b出现故障或网络延迟，在高并发的情况下，服务b会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务b的不可用。如果服务b为较底层的服务，会影响到其他服务，导致其他服务会一直等待服务b的处理。如果服务b迟迟不处理，大量的网络请求不仅仅堆积在服务b，而且会堆积到依赖于服务b的其他服务。因而服务b出现故障影响的服务，也会影响到依赖于服务b出现故障影响的服务的其他服务，从而由b开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。

为了解决这一难题，微服务架构引入了熔断机制。当服务b出现故障，请求失败次数超过设定的阈值之后，服务b就会开启熔断器，之后服务b不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于b的服务就不会因为得不到响应而线程阻塞，这时除了服务b和依赖于服务b的部分功能不可用外，其他功能正常。熔断服务如下图所示：



熔断器还有另外一个机制，即自我修复的机制。当服务b熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其他请求执行快速失败，检查的请求如果响应成功，则可以判定服务b正常了，就会关闭服务b的熔断器；如果服务b还不正常，则继续打开熔断器。这种自我熔断机制和自我修复机制在微服务架构中有着重要的意义，一方面它使程序更加健壮，另一方面为开发和运维减少很多不必要的工作。

最后熔断组件往往会提供一系列的监控，例如服务可用与否、熔断器是否打开、目前的吞吐量、网络延迟状态的监控等，从而很容易让开发人员和运维人员实时了解服务的状态。

二.微服务的优势

相对于单体服务来说，微服务具有很多优势，主要体现在以下方面：

1)将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。服务按照业务拆分，编码也是按照业务来拆分，代码的可读性和可扩展性增加。新人加入团队，不需要了解所有的业务代码，只需要了解他所接管的服务的代码，新人学习时间成本减少。

2)由于微服务系统是分布式系统，服务与服务之间没有任何的耦合。随着业务的增加，可以根据业务再拆分服务，具有极强的横向扩展能力。随着应用的用户量的增加，并发量增加，可以将微服务集群化部署，从而增加系统的负载能力。简而言之，微服务系统的微服务单元具有很强的横向扩展能力。

3)服务与服务之间通过HTTP网络通信协议来通信，单个微服务内部高度耦合，服务与服务之间完全独立，无耦合。这使得微服务可以采用任何开发语言和技术来实现。开发人员不再被强迫使用公司以前的技术或已经过时的技术，而是可以自由选择最合适业务场景的或适合自己的开发语言和技术，提供开发效率、减低开发成本。

4)如果是一个单体的应用，由于业务的复杂性、代码的耦合性，以及可能存在的历史问题。在重写一个单体应用时，要求重写应用的人员了解所有的业务，所以重写单体应用是非常困难的，并且重写风险也很高。如果是微服务系统，由于为服务是按照业务的进行拆分的，并且有坚实的服务边界，所以重写某个服务就相当于重写某一个业务的代码，非常简单。

5)微服务的每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其它服务没有影响。试想，假设一个应用只有一个简单的修改，如果是单体架构，需要测试和部署整个应用；而如果采用微服务架构，只需要测试并部署被修改的那个服务，这就大大减少了测试和部署的时间。

6)微服务在CAP理论中采用的是AP架构，即具有高可用和分区容错的特点。高可用主要体现在系统7*24小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系统的负载能力。另外，分区容错也使得系统更加健壮。

三.微服务的不足

凡事都有两面性，微服务也不例外，微服务相对于单体应用来说具有很多的优势，当然也有其不足之处，主要体现在如下方面：

1.微服务的复杂度

构建一个微服务系统并不是一件容易的事，微服务系统是分布式系统，构建的复杂度远远超过单体系统，开发人员需要付出一定的学习成本去掌握跟过的架构知识和框架知识。服务于服务之间通过HTTP协议或消息传递机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。

另外服务与服务之间相互依赖，如果修改某一个服务，会对另外一个服务产生影响，如果掌控不好，会产生不必要的麻烦。由于服务的依赖性，测试也会变得复杂，比如修改一个比较基础的服务，可能需要重启所有的服务才能完成测试。

2.分布式事务

微服务架构所设计的系统是分布式系统。分布式系统有一个著名的CAP理论，即同时满足"一致性"、"可用性"和"分区容错"是一件不可能的事。CAP理论是有Eric Brewer在2000年PODC会议上提出的，该理论在两年后被证明成类。CAP理论告诉架构师不要妄想设计出同时满足三者的系统，应该有所取舍，设计出适合业务的系统。CAP理论如下如所示：

• Consistency：指数据的强一致性，如果写入某个数据成功，之后读取，读到的都是新写入的数据；如果写入失败，之后读取的都不是写入失败的数据；
• Aavilability：指服务的可用性；
• Partition-tolerrance：指分区容错；

在分布式系统中，P是基本要求，而单体服务是CA系统。微服务系统通常是一个AP系统，即同时满足可用性和分区容错。这就有了一个难题：在分布式系统中如何确保数据的一致性？这就是大家经常讨论的分布式事务。

在微服务系统中，每个服务都是独立的进程单元，每个服务都有自己的数据库。通常情况下，只有关系型数据库在特定的数据引擎下才支持事务，而大多数非关系型数据库是不支持事务的，例如MongoDB是不支持事物的，而Redis是支持事务的。在微服务架构中，分布式事务一直都是一个难以解决的问题，业界给出的解决方案通常是两阶段提交。

网上购物在日常生活中是一个非常普通的场景，假设我们在淘宝上买了一部手机，需要从我的账户中扣除1000元钱，同时手机的库存数量需要减1.当然需要在卖方的账户中加1000元钱，为了使案例简单化，暂时不用考虑其他。

如果这是一个单体应用，并且使用支持事物的MySQL数据库(InnoDB数据库引擎才支持事务)，我们可以这样写代码：

@Transacntional
public void update() throws RuntimeException{
    updateAccountTable();        // 更新账户表
    updateGoodsTable();        // 更新商品表
}

如果是微服务架构，账户是一个服务，而商品是一个服务，这时不能用数据库自带的事务，因为这两个数据表不在一个数据库中。因此常常用到两个阶段提交，两个阶段提交的过程如下如所示：



第一阶段，service-account发起一个分布式事务，交给事务协调器TC处理，事务协调器TC向所有参与的事务的节点发送处理事务操作的准备操作。所有的参与节点执行准备操作，将Undo和Redo信息写入日志，并向事务管理器返回准备操作是否成功；

第二阶段，事务管理器收集所有节点的准备操作是否成功，如果都成功，则通知所有的节点执行提交操作；如果有一个失败，则执行回滚操作；

两阶段提交，将事务分成两部分能够大大提高分布式事务成功的概率。如果在第一阶段都成功了，而执行第二阶段的某一个节点失败，仍然导致数据的不准确，这时一般需要人工去处理，这就是当初在第一步记录日志的原因。另外，如果分布式事务涉及的节点很多，某一个节点的网络出现异常会导致整个事务处于阻塞状态，大大降低数据库的性能。所以一般情况下，尽量少用分布式事务。

3.服务的划分

将一个完整的系统拆分成很多个服务，是一件非常困难的事，因为这涉及到了具体的业务长江，比明明一个类更加困难。对于微服务的拆分原则，Martin Fowler给出的建议是：服务是可以被替换和更新的。也就是服务和服务之间无耦合，任何一个服务都可以被替换，服务有自己严格的边界。当然这个原则很抽象，根据具体的业务场景来拆分服务，需要依靠团队人员对业务的熟悉程度和理解程度，并考虑与已有架构的冲入、业务的扩展性、开发的风险和未来业务的发展等诸多因素。

领域驱动设计是一个全新的概念，也是一个比较理想的微服务拆分的理念。领域驱动设计通过代码和数据分析找到合理的切分点，并通过数据分析来判断服务的划分边界和划分粒度。目前来说，在中国几乎没有公司去落地领域驱动设计这个理念，随着微服务的发展，这一理念在以后有可能会落地。

4.服务的部署

一个简单的单体系统可能只需要将程序集群部署并配置负载均衡服务器即可，而部署一个复杂的微服务架构的系统就复杂得多。因为每一个微服务可能还涉及比较低层的组件，例如数据库、消息中间件等。微服务系统往往由数量众多的服务构成，例如Netflix公司大约有600个服务，而每个服务又有大量的实例。微服务系统需要对每个服务进行治理、监控和管理等，而每个服务有大量的配置，还需要考虑服务的启动顺序和启动时机等。

部署微服务系统，需要开发人员或者运维人员对微服务系统有足够强的控制力。随着云计算和云服务器的发展，部署微服务系统并不是一件难事，例如使用PaaS服务、使用Docker编排等。这就是人们往往提到微服务，就会想到Docker、DevOps的原因。其中，微服务是核心；Docker为容器技术，是微服务最佳部署的容器；DevOps是一种部署手段或理念，他们的关系如图所示：

四.微服务和SOA的关系

SOA即面向服务的架构，这种架构在20年前就已经被提出了。SOA往往与企业服务总线(ESB)联系在一起，主要原因在于SOA的实施思路是根据ESB模式来整合集成大量单一庞大的系统，这是SOA主要的落地方式。然而，SOA在过去20年并没有取得成功。在谈到微服务时，人们很容易联想到它是一个面向服务的架构，的确，微服务的概念提出者Martin Fowler并没有否认这一层关系。

微服务相对于和ESB联系在一起的SOA显然轻便敏捷得多，微服务将复杂的业务组件化，实际也是一种面向服务思想的体现。对于微服务来说，它是SOA的一种实现，但是它比ESB实现的SOA更加轻便、敏捷和简单。

五.微服务的设计原则

软件设计就好比建筑设计。Architect这个词在建筑学中是"建筑师"的意思，而在软件领域则是"架构师"的意思，可见它们确实有相似之处。无论是建筑师还是架构师，他们都希望把作品设计出自己的特色，并且更愿意把创造出来的东西称之为艺术品。然而现实却是，建筑设计和软件设计有非常大的区别。建筑师设计并建造出来的建筑往往很难有变化，除非拆了重建。而架构师设计出来的软件系统，为了满足产品的业务发展，在它的整个生命周期中，每一个版本都有很多的变化。

软件设计每一个版本都在变化，所以软件设计应该是渐进式发展。软件从一开始就不应该被设计成微服务架构，微服务架构固然有优势，但是它需要更多的资源，包括服务器资源、技术人员等。追去大公司所带来的技术解决方案，刻意地追求某个新技术，企图使用新技术解决所有的问题，这些都是软件设计的误区。

技术应该是随着业务的发展而发展的，任何脱离业务的技术是不能产生价值的。在初创公司，业务很单一时，如果在LAMP单体架构够用的情况下，就应该用LAMP，因为它开发速度快，性价比高。随着业务的发展，用户量的增加，可以考虑将数据库读写分离、加缓存、加负载均衡器、将应用程序集群化部署等。如果业务还在不断发展，这时可以考虑使用分布式系统，例如微服务架构的系统。不管使用什么样的架构，驱动架构发展的一定是业务的发展，只有当前架构不适合当前业务的发展，才考虑更换架构。

在微服务架构中，有三大难题，那就是服务故障的传播性、服务的划分和分布式事务。在微服务设计时，一定要考虑清楚这三个难题，从而选择合适的框架。目前比较流行的微服务框架有Spring社区的Spring Cloud、Google公司的Kubernetes等。不管使用哪一种框架或者工具，都需要考虑这三大难题。为了解决服务故障的传播性，一般的微服务框架都有熔断机制组件。另外，服务的划分没有具体的划分方法，一般来说根据业务来划分服务，领域驱动设计具有指导作用。最后，分布式事务一般的解决办法就是两阶段提交或者三阶段提交，不管使用哪一种都存在事务失败，导致数据不一致的情况，关键时刻还得人工去恢复数据。总之，微服务的设计一定是渐进式的，并且是随着业务的发展而发展的。