# 微服务架构设计模式
# 介绍
一种具有更高可维护性、可测试性和可部署性的架构风格。微服务不是银弹： 它存在包括复杂性在内的诸多弊端。
# 概念
# 软件架构
是一种抽象的结构，它由软件的各个组成部分和这些部分之间的依赖关系构成。架构很重要的原因是它决定了应用程序的质量属性或能力。传统上，架构的目的是可拓展性、可靠性和安全性。
# 视图模型
软件架构的4+1视图模型：
- 逻辑视图： 开发人员创建的软件元素。eg: 类和包之间的关系，包括继承、关联和依赖
- 实现视图： 构建编译系统的输出。eg: 组件是由一个或多个模块组成的可执行或可部署单元
- 进程视图： 运行时的组件。 每个元素都是一个进程，进程之间的关系代表进程间通信
- 部署视图： 进程如何映射到机器。此视图中的元素由计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系
- 场景： 将视图串联在一起。每个场景描述在一个的多个架构元素如何协作，以完成一个请求。
# 软件架构的作用
应用程序由两个层面的需求。
功能性需求： 决定一个应用程序做什么。通常包含在用例或者用户故事中非功能性需求： 这类需求也成为质量属性需求，或者称为能力。这些非功能性需求决定一个应用程序在运行时的质量。 eg: 可拓展性、可靠性、可维护性、可测性、可部署性等。
# 分层式架构风格
将软件元素按“层”的方式组织，每层都有明确定义的职责。分层架构还限制了层之间的依赖关系，每一层只能依赖于紧邻其下方的层或其下面的任何层。
# 三层架构
应用于逻辑视图分离的分层架构，它将应用程序的类组织到以下层中：
- 表现层： 包含实现用户界面或外部API的代码
- 业务逻辑层： 包含业务逻辑
- 数据持久化层： 实现与数据库交互的逻辑
# 弊端
- 单个表现层： 无法展现应用程序可能不仅仅由单个系统调用的事实
- 单一数据持久化层： 它无法展现应用程序可能与多个数据库进行交互的事实
- 将业务逻辑层定义为依赖于数据持久化层： 理论上，这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑