这是我参与「第五届青训营 」伴学笔记创作活动的第十三天。今天学习了有关微服务架构原理的课程，老师从最开始的单体架构一步步的带我们学习了随着行业的发展，架构是如何进化的。
随着互联网的发展和项目的体积不断扩大，开发人员不断增加，这就意味着我们需要不断拆分项目来简化方便管理，从最开始的单体项目到现在的微服务项目，老师带我们分析二者之间迭代的每个阶段的特点：
- 单体架构：顾名思义单体架构就是把所有代码都写在一个项目中，因为不涉及到远程调用等操作所以性能会比较高，但冗长的代码必然会来带debug的不便，想要在成千上万条代码中定位错误，犹如大海捞针，并且还会因为一些非核心业务的错误而影响核心业务的正常运行。项目业务比较简单时可以考虑这种架构。
- 垂直应用架构：按照业务线垂直划分，将项目按照不同业务进行拆分，比如我们常见的将项目分成前台系统和后台系统，前台系统用来处理用户发出的所有请求，后台系统用来处理管理员对数据库的操作请求，虽然做了拆分但每个业务严格来说还是单体。
- 分布式架构：在原来垂直应用架构的基础上，抽出业务无关的公共模块组成不同的业务服务，比如后台系统中我们可以将专门处理用户的所有请求抽出并放在一起来组成用户服务，当别的服务需要本服务时可以来调用本服务的接口获取数据。这种架构存在劣势也很明显，当一个服务出现问题可能导致一连串的服务瘫痪，而且调用关系错综复杂。
- SOA架构：在分布式架构的基础上增加了注册中心来管理所有服务，它为所有的服务提供了注册与发现的功能，这样避免了因为一个模块的问题而导致整个项目崩溃的情况，但该架构需要从上到下去设计，重构会很困难。
- 微服务架构：微服务架构做到了彻底将项目服务化，打破了之前按照不同业务进行拆分的规则，利用消息队列完成不同服务之间的通信，将错误隔离在对应的服务上，该架构仍然存在分布式系统复杂的特性。
