版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/han1196639488/article/details/80241820
说到微服务架构，我们先不谈微服务架构，先说一说单体应用架构。
* 单体应用架构的问题*
一个归档包（war包）包含的所有功能的应用程序，通常称之为单体应用。而架构单体应用的方法论就是单体应用架构。
以一个电影售票系统为例，
相信很多项目都是从单体应用开始的，所有的业务模块耦合在一起，这样的单体应用比较容易部署，测试，在项目初期确实可以很好的运行。然而随着需求的增加，越来越多人加入开发团队，代码库也在飞速膨胀，慢慢的单体应用变得越来越臃肿，可维护性，灵活性逐渐降低，维护成本 越来越高。下面列举一些单体应用的问题：
- 复杂性高：单体百万行代码的项目包含的模块非常多，模块边界模糊，依赖关系不明确，代码质量残次不齐，每次改代码都心惊胆战，添加一个简单的功能都会带来隐含的缺陷。
- 技术债务：随着时间的推移，需求和开发人员更迭，会逐渐形成应用程序的技术债务，不坏不修很常见，已使用的系统设计难以被修改
- 部署频率低：随着代码的增多，构建和部署时间也会增加，每次功能的变更或者修复都会导致重新部署整个应用。全量部署的方式耗时长，影响范围大，风险高，这使得单体应用部署上线频率降低，而部署频率的降低又会导致两次发布版本之间大量的功能变更和修改，出错概率比较高。
- 可靠性差：某个模块bug，死循环，oom导致整个应用的崩溃。
- 拓展能力受限：单体应用只能作为一个整体进行拓展，无法根据业务模块的需要进行伸缩，列如：应用中有的是计算密集型，他需要强筋的cpu，有的是io密集型，他需要更大的内存。全部部署在一起的话需要综合考虑。
微服务就解决了上述的问题：
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通讯采用轻量级通信机制（http）。这些服务公用一个最小型的集中式的管理，服务可用不同语言开发，使用不同数据存储技术。
微服务的优点：
- 易于开发与维护：一个微服务只关心一个特定的业务功能，所以他业务清晰，代码量较少。
- 单个微服务启动快
- 局部修改容易部署：微服务只需要部署修改的服务即可
- 技术栈不受限：每个服务可用不同的开发语言
按需伸缩：可根据不同的需求，实现细粒度的拓展。
微服务的缺点：
运维要求高：服务更多意味着运维的投入，单体应用只需保证一个应用的正常运行，而在微服务中，需要保证几十上百的服务正常运行与协作。
- 分布式固有的复杂性：使用微服务构建的是分布式系统。
- 接口调整成本高：微服务时间通过接口进行通信，如果修改某一个微服务的api，可能使所有使用该接口的微服务都做调整
- 重复劳动：很多服务使用相同的功能，而这个功能每个服务都写一次，导致代码重复，即便可以开发为公共组件，但可能服务间语言不同导致不通。
微服务架构图
