1 从单体架构到微服务

1.1 单体架构

Web应用程序发展的早期，大部分web工程师将所有的功能模块打包到一起并放在一个web容器中运行，所有功能

模块使用同一个数据库，同时，它还提供API或者UI访问的web模块等。

尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用，这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构（也叫：巨石型应用）。

单体架构有很多好处：

开发效率高：模块之间交互采用本地方法调用，并节省微服务之间的交互讨论时间与开发成本。

容易测试：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统。

容易部署：运维成本小，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。

但是，上述的好处是有条件的，它适用于小型简单应用，对于大规模的复杂应用，就会展现出来以下的不足：

复杂性逐渐变高，可维护性逐渐变差 ：所有业务模块部署在一起，复杂度越来越高，修改时牵一发动全身。

版本迭代速度逐渐变慢：修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。

阻碍技术创新：若更新技术框架，除非你愿意将系统全部重写，无法实现部分技术更新。

无法按需伸缩：通过冗余部署完整应用的方式来实现水平扩展，无法针对某业务按需伸缩。

1.2 微服务

许多大型公司，通过采用微服务架构解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。

一个微服务一般完成某个特定的功能，比如订单服务、用户服务等等。每一个微服务都是完整应用，都有自己的业务逻辑和数据库。一些微服务还会发布API给其它微服务和应用客户端使用。

比如，根据前面描述系统可能的分解如下：

每一个业务模块都使用独立的服务完成，这种微服务架构模式也影响了应用和数据库之间的关系，不像传统多个业务模块共享一个数据库，微服务架构每个服务都有自己的数据库。

微服务架构的好处：

• 分而治之，职责单一；易于开发、理解和维护、方便团队的拆分和管理
• 可伸缩；能够单独的对指定的服务进行伸缩
• 局部容易修改，容易替换，容易部署，有利于持续集成和快速迭代
• 不会受限于任何技术栈

2 分布式应用配置管理

下图展示了如何通过Nacos集中管理多个服务的配置：

用户通过Nacos Server的控制台集中对多个服务的配置进行管理。

各服务统一从Nacos Server中获取各自的配置，并监听配置的变化。

2.1 发布配置

首先在nacos发布配置，我们规划了两个服务service1、service2，并且想对这两个服务的配置进行集中维护。

浏览器访问 http://192.168.222.144:8848/nacos ，打开nacos控制台，并点击菜单配置管理->配置列表：

在Nacos添加如下的配置：

service1

Namespace: c67e4a97‐a698‐4d6d‐9bb1‐cfac5f5b51c4 #开发环境
Data ID: service1.yaml
Group : TEST_GROUP
配置格式: YAML
配置内容： common:
             name: service1 config

 

service2

Namespace: c67e4a97‐a698‐4d6d‐9bb1‐cfac5f5b51c4 #开发环境
Data ID: service2.yaml
Group : TEST_GROUP
配置格式: YAML
配置内容： common:
             name: service2 config