微服务是将功能分割成一个一个可以自治管理的模块，模块通过REST API或RPC对外提供服务，它隔离了功能模块，极大地解耦了模块之间的数据，并且可以通过负载均衡增加单个服务的处理能力，同时也提高了整个系统的扩展能力
Monolith单体架构
早期的软件运行于单体系统中，功能少且单一，所有代码在一个项目中，功能上没有明确的边界，模块间函数互相调用，功能模块之间通过代码级别的引用建立依赖关系，模块功能发生变化就不得不考虑依赖关系的影响，随着功能越来越多，整个系统越来越臃肿，最终发展到难以维护的地步，并且性能无法轻松的扩展，总结起来就是扩展能力差、逻辑耦合严重、系统升级非常麻烦
然而单一架构依然可以进行分层，进行前后端分离等处理，但仍旧无法解决这种架构下的顽疾
分布式架构和SOA
说到分布式就不能不提SOA(Service-Oriented Architecture)，即面向服务的分布式架构，通过代码的分离使得每个功能都可以作为一个服务单独部署，并且服务间进行了充分的解耦，每个服务都明确的边界，服务间的相互调用则通过中立的契约来描述，如此不同的服务可以由不同的平台进行实现，例如对于高性能的服务可以使用C++来实现，对于需要高速开发和快速功能迭代的可以使用Java或Python来实现
分布式架构基于网络的服务器架构集群，可以轻松的进行流量负载均衡，并且当一个服务所部属的服务器出现性能瓶颈时，可以通过升级该服务器或者增加服务器集群快速提升服务能力
微服务
微服务和SOA有类似之处，都是将模块组件服务化，每个服务通过API对外提供特定的服务，但微服务有自身的特点，较SOA，它更加组件化，从而会生成更多的自治服务模块，简单的说，就是以实现一组微服务的方式来开发一个独立的应用系统的方法，其中每个小微服务都运行在自己的进程中，通常采用基于HTTP协议的资源API这样轻量的机制进行通信
微服务围绕业务功能进行构建，通过全自动化的方式进行独立部署，可以使用不同的编程语言来编写，也可以使用不同的存储技术，并且进行最低限度的集中管理
- 微服务将团队分割成一个一个小的团队，每个团队负责自己的微服务开发，便于管理，执行力高
- 服务是高可用的，一个服务可以发起多个进程提供同样的服务，通过负载均衡算法决定调用哪个进程的服务
- 非常高的横向扩展能力，一个服务遇到瓶颈，可以通过启动更多的服务进程来提高并发处理能力
- 灰度发布，微服务架构下的缺陷修复，不再需要统一的版本控制，如果一个问题可以很简单的修复，并且这个服务在系统中运行了100个进程，那么可以先给10个进程做升级，然后看看实际运行过程中是否有问题也就是测试结果而定是否要升级其他进程，即便有问题也只是影响了10%的流量，可以回退版本继续修复
微服务难题
- 过于自治的服务导致联调成本巨大，特别是对于接口的定义频繁变动的团队而言，沟通成本也巨大
- 数据一致性问题，服务被拆成了小块，有些操作就要有事务的概念，因为服务不允许存在状态，当一个事务包含多个微服务的调用的时候就要解决数据的竞争问题，也就是数据一致性问题
- 运维难度变大，随着服务越来越多，运维难度也逐渐加大，对CICD的成熟程度是个考验