开发者学堂课程【Spring Cloud Alibaba Nacos 详解（上）：应用于分布式系统-从单体架构到微服务架构】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/724/detail/12924
应用于分布式系统-从单体架构到微服务架构
内容介绍
一、单体架构
二、微服务架构
我们使用 nacos 主要是用在分布式系统开发，我们会采用微服务架构来开发我们系统的所有服务。
Nacos 是充当使用配置中心的一个解决方案，所以使用 nacos 如何应用到分布式系统开发中是我们所需要研究的重点。
一、单体架构
单体架构，它是早期应用比较多的架构。
Web 应用程序发展的早期，大部分 web 工程师将所有的功能模块打包到一起并放在一个 web 容器中运行，所有功能模块使用同一个数据库，同时，它还提供 API 或者 u访问的 web 模块等。
尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用，这种将所有功能都部署在一个 web 容器中运行的系统就叫做单体架构（也叫:巨石型应用)。
对于小型项目单体架构比较快捷方便，但是对于大型项目这种架构还存在很多问题。
单体架构有很多好处：
开发效率高：模块之间交互采用本地方法调用，并节省微服务之间的交互讨论时间和开发成本。 （但是如果项目功能很多，再加上其他的一些模块，这时我们会发现功能层会变成一个巨石型的应用。到那时开发效率就不会高，因为模块与模块之间的依赖变多，处理的复杂性很高，维护性也会变差。只要有一个模块修改，整个工层就会改变，打包的效率就会低。）
容易测试︰IDE 都是为开发单个应用设计的、容易测试――在本地就可以启动完整的系统。容易部署︰运维成本小，直接打包为一个完整的包，拷贝到 web 容器的某个目录下即可运行。
但是，上述的好处是有条件的，它适用于小型简单应用，对于大规模的复杂应用，就会展现出来以下的不足:
不足：
复杂性逐渐变高，可维护性逐渐变差︰所有业务模块部署在一起，复杂度越来越高，修改时牵一发动全身。版本迭代速度逐渐变慢∶修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。
版本迭代速度逐渐变慢∶修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。
阻碍技术创新︰若更新技术框架，除非你愿意将系统全部重写，无法实现部分技术更新。
无法按需伸缩∶通过冗余部署完整应用的方式来实现水平扩展，无法针对某业务按需伸缩。
二、微服务架构
那么如何改变这些问题呢？就到了微服务架构。它会将每个系统的模块独立成一个具体的小型的项目，可以理解成一个一个的工程。是为了可维护性、可扩展性方便才这样设计。
许多大型公司，通过采用微服务架构解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能，比如订单服务、用户服务等等。每一个微服务都是完整应用，都有自己的业务逻辑和数据库。一些微服务还会发布AP!给其它微服务和应用客户端使用。
比如，根据前面描述系统可能的分解如下:
用户服务是一个独立的工程，会连接单独用户服务的用户库；商品服务是一个工程，连接商品库……它们都是相互独立的，虽然用户服务商品服务等之间有联系，但是也是通过标准的接口进行交互，不会出现在一个工程中出现很多功能模块，一个功能模块变更，其它都需要改变这一问题。
当系统越来越大，很多服务就会诞生，每一个服务就称为微服务，每一个服务也是独立的项目和工程。
每一个业务模块都使用独立的服务完成，这种微服务架构模式也影响了应用和数据库之间的关系，不像传统多个业务模块共享一个数据库，微服务架构每个服务都有自己的数据库。
微服务架构的好处:
·分而治之，职责单一;易于开发、理解和维护、方便团队的拆分和管理
·可伸缩;能够单独的对指定的服务进行伸缩（用户服务的修改变更不会影响到商品服务，同时将微服务部署到生产环境上，根据每个服务的性能需要，可以对每个服务进行平滑的扩容。由于把各个服务分开，不论是在开发还是生产都方便我们去维护）
·局部容易修改，容易替换，容易部署，有利于持续集成和快速迭代
·不会受限于任何技术栈
所以从单体架构演变为微服务架构，是根据当前的软件需要所改变的，所以微服务架构更适合用于大项目，针对当前互联网项目来说，微服务架构使用更多。
