微服务架构.pptx

6
5
4
3
2
1
目
录
CONTENTS
微服务的诞生
具体应用
Monolith
微服务架构的优点与缺点
微服务的定义
微服务架构模式
1
微服务的诞生
微服务架构（Microservice Architect）是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
背景
微服务的诞生并非偶然。它是互联网高速 发展，敏捷、精益、持续交付方法论的深入人 心，虚拟化技 术与DevOps 文化的快速发 展以及传统单 块架构无法适 应快速变化等 多重因素的推 动下所诞生的 产物
2
Monolith
通常，要开发的服务所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。
在编译时，这些项目将被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。接下来，我们需要将该WAR包上传到Web容器中，解压该WAR包，并重新启动服务器。
在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了
这种将所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后，编译器编译代码，然后软件开发人员花费一分钟部署刚刚编译出来的WAR包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。
如果应用的部署非常麻烦，那么为了对自己 的更改进行测试，软件开发人员还需要在部署 前进行大量的环境设置，进而使得软件开发人员 的工作变得繁杂而无趣
从上面的示意图中可以看到，在应用变大之后，软件开发人员花在编译及部署的时间明显增多，甚至超过了他对代码进行更改并测试的时间，效率已经变得十分低下。