微服务简介

微服务的简介

​ 随着互联网技术飞速发展，目前全球超过一半的人口在使用互联网的产品，人们的生活随着互联网的发展，发生了翻天覆地的变化。各行各业都在你使用互联网，国家政策也在大力支持互联网的发展，随着越来越多的用户参与，业务场景越来越复杂，传统的单体架构已经很难满足互联网技术的发展需求。这主要体现在两个方面，一是随着业务复杂度的提高，代码的可维护性降低；二是维护系统的成本、修改系统的成本在提高。所以，改变单体应用架构已经势在必行。另外，随着计算机、大数据、人工智能的飞速发展，对系统架构也提出了越来越高的要求

​ 微服务，是著名的 OO（面向对象，Object Oriented）专家 Martin Fowler提出来的，用来描述将软件应用和程序设计为独立部署的服务。最近两年，微服务在各大技术会议、文章、书籍上出现的频率，已经让人们意识到他对于软件领域所带来的影响力。微服务的系统是一个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，他能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。

1.1 单体架构及其存在的不足

1.1.1单体架构简介

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

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

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

1.1.2 单体架构存在的不足

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

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

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

​ 随着业务的发展，大多数公司将单体应用进行及一群部署，并增加负载均衡服务器（例如Nginx等）。另外，还需要增加集群部署的缓存服务器和文件服务器，并将数据库读写分离，以应对用户量的增加而带来的高并发访问量。

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

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

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

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

1.2 微服务

​ 微服务是近几年才出现的新名词，它在各大技术社区、博客、论坛和新闻报道中经常被提及，是程序员和架构师经常讨论的话题。的确，微服务已经是技术圈的热门话题，那么到底什么是微服务呢？微服务产生的意义又是什么呢？微服务有哪些优势和缺点？另外，微服务与SOA有什么关系？

1.2.1 什么是微服务

​ “微服务”最初是由Martin Fowler 在2014年写的一篇《MicroServices》中提出来的。关于Martin Fowler的介绍如下

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

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

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

微服务具有如下特点

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

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

​ 微服务的 “微” 到底需要定义什么样的程度，这是一个非常难以界定的概念，可以从以下三个方面来界定：

1. 根据代码量来定义，更具代码量的多少来判断程序的大小
2. 根据开发时间长短来判断
3. 根据业务的大小来划分

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

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

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

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

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

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

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

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

3 微服务的数据库独立

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

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

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

4 微服务的自动化部署

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

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

5 服务集中化管理

​ 微服务系统是按业务单元来划分的，服务数量越多，管理起来越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如：Spring Cloud 支持用 Eureka、Zookecper 和 Consul 来注册服务和发现服务，领外，Eureka和Nacos等都是非常优秀的服务注册和发现组件。

6 分布式架构

​ 分布式系统都是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。

​ 分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完成。

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

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

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

7 熔断机制

​ 为了防止 “雪崩效应” 事件的发生，分布式系统采用了熔断机制。在用 Spring Cloud构建的微服务系统中，采用了熔断器（即Hystriix组件的Circit Breaker）去做熔断。

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

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

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

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

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

1.2.2 微服务的优势

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

1. 将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界没明确，将复杂的问题简单化。服务按照业务分析，编码也是按照业务来分析，代码的可读性可扩展性增加。新人加入团队，不需要了解所有的代码，只需要了解它所接管的服务的代码，新人学习的时间成本减少。
2. 由于微服务系统是分布式系统，服务与服务之间没有任何的耦合。随着业务的增加，可以根据业务再拆分服务，具有极强的横向扩展能力。随着应用的用户量增加，并发量增加，可以将微服务集群化部署，从而增加系统的负载能力。简而言之，微服务系统的微服务单元具有极强的横向扩展能力
3. 服务与服务之间通过HTTP网络通信协议来通信，单个服务内部高度耦合，服务与服务之间完全独立，无耦合。这使得微服务可以采用任何的开发语言和技术来实现。开发人员不在被迫使用公司以前的技术或者已经过时的技术，而是可以自由选择最合适业务场景的或者最适合自己开发语言和技术，提高开发效率，降低开发成本。
4. 如果是一个单体的应用，由于业务的复杂性、代码的耦合性，已经可以存在的历史问题。在重写一个单体应用时，要求重写的应用的人员了解所有的业务，所以重写单体应用时非常困难的，并且重写风险也较高。如果是微服务系统共，由于微服务系统是按照业务的进行拆分的，并且有坚实的服务边界，所以重写某个就相当于某一个业务的代码，非常简单。
5. 微服务的没每个服务单元都是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。试想，假设一个应用只有一个简单的修改，如果是单体架构，需要测试和部署整个应用；而如果采用微服务架构，只需要测试并部署被修改的那个服务，这就大大减少了测试和部署的时间。
6. 微服务在CAP理论中是AP架构，即具有高可用和分区容错的特点。高可用主要体现在系统 7 × 24 小时不间断的服务，他要求系统有大量的服务器集群，从而提高了系统的负载能力。另外，分区容错也使得系统更加健壮。

1.3 微服务的不足

​ 凡事都有两面性，微服务也不例外，微服务相对于单体架构来说具有很多的优势，当然也有它的不足，主要体现在以下几个方面：

1. 微服务的复杂度
2. 分布式事务
3. 服务的划分
4. 服务的部署

1.3.1 微服务的复杂度

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

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

1.3.2 分布式事务

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

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

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

​ 在微服务系统中，每个服务都是独立的进程单元，每个服务都有自己的数据库。通常情况下，只有关系型数据库在特定的数据引擎下才支持事务，而大多数非关系型数据库是不支持事务的，例如MongDB是不支持事务的，而Redis是支持事务的。在微服务架构中，分布式事务一直是一个那一解决的问题，业界给出了跟多解决的办法，比如两阶段提交、三阶段提交、TCC等。两阶段提交介绍。

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

​ 比如这是一个单体应用，并且使用支持事务的MySQL数据库（InnoDB 数据库引擎才支持事务），我们可能这样写代码：

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

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

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

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

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

1.3.3 服务划分

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

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

1.3.4 服务的部署

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

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

1.4 微服务和SOA的关系

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

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

1.5 微服务于的设计原则

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

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

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

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