每天分享一个Java知识点并不容易。喜欢的话可以关注，配合学习。

20191205年的软件开发历史，充满了大量开发项目的故事，是在投入了数百万美元、数十万软件开发人员的时间之后才举行的。这些庞大的项目往往遵循大规模的传统瀑布开发方法，坚持在项目一开始就定义所有应用法语的需求和设计。

过于强调让所有规格的软件都“正确”，没有空间去满足新的业务需求，也没有空间去重构和学习成长初期犯下的错误。但实际情况是，软件开发不是一个定义和执行的线性过程，而是一个渐进的过程。

在开发团队真正了解手头的问题之前，它需要频繁地、反复地与客户沟通、学习和交付。联合使用传统瀑布方法的挑战在于，在这些项目中交付的软件产品的粒度是：1。

紧密耦合：这大大增加了即使应用法语组合键做了小改动，也有可能破坏其他应用法语的部门，引入新的bug的机会；2.漏洞：大多数大型软件应用程序对不同类型的数据应用法国治理。例如，客户关系管理(CRM)可以管理客户、销售和产品信息。在传统模型中，这些数据存在于一个数据模型中，并存储在同一个数据存储中。虽然数据之间有明显的界限，但是对于来自一个领域的团队来说，直接遇到属于另一个团队的数据通常是很容易的。

这种易于满足的数据建立了隐藏的依赖关系，并允许组件内部数据结构的实现细节泄漏到整个应用程序中。即使对单个数据库表的微小更改也可能需要在整个应用程序中进行大量的代码更改和回归测试。3.单体/巨大：由于一个传统应用法语的大部分应用法语组件都存在于单个代码库中，由多个团队共享，代码随时更改，整个法语必须重新编译，重新运行整个测试周期，并进行worm部署。

即使是对应用法语代码库的微小更改，无论是新的客户需求还是bug修复，都会变得昂贵而耗时，大的更改也很难实时完成。微服务架构接受不同的方法来提供功效。具体来说，微服务架构具有以下特征：1 .有限：微服务职责单一，规模有限。

微服务包含了Unix哲学：一个应用程序只不过是服务的集合，每个服务做一件事，做好一件事；2.松耦合：一个微服务应用是一个小服务的集合，它只使用非专有的挪用协议(比如Http和Rest)，不执行特定的接口交互。只要服务不改变接口，微服务的拥有者比传统应用架构中有更多的修改服务的自由；3.分散：微服务有自己的数据结构和数据源。来自微服务的数据只能由服务修改。

数据库的会议控制锁定了微服务的数据，只允许这个服务满足；4.独立：微服务应用程序方法中的每个微服务都可以独立于应用程序方法中的其他服务进行编译和部署。这意味着，与更加相互依赖的整体应用方法相比，变更可以更容易地被隔离和测试。为什么这些微服务架构属性对于基于云计算的开发很重要？基于云的应用方法一般有以下特点：1。

庞大多样的用户群体：不同的客户需要不同的特性，不需要等待很长的应用方法发布周期才开始使用这些特性。微服务可以快速提供功效，因为每个服务都是小规模的，并且通过一个定义明确的接口来满足；2.极高的正常运行时间要求：由于微服务的撤离，微服务应用可以更容易地隔离应用方法特定部门的故障和问题，而无需删除整个应用方法。

这减少了整个应用程序的停机时间，并提高了它们抵抗故障的能力。3.巨大的需求：随着时间的推移，部署在被墙包围的企业数据中心的传统应用方法通常具有一致的使用模式。这使得这些类型的法国产能规划变得简单。但是，在一个基于云的应用中，在Twitter上发一条简单的推文，或者在Slashdot上发一条消息，都可以最大程度的带动云应用需求。

想要得到完整面试问题和答案的同学请夸奖，关注，转发。私信拥有者：“Java面试题”获取完整信息，有spring、jvm、linux、docker等超完整电子书。面试重点知识点200多页，内容全面，需要私信。本文引自《Spring微服务实战（2016中文版）》。

本文来源：开元游戏app-www.dexingtong168.com