微服务架构

一、单体架构

• 一个归档包包含了应用所有功能的应用程序，我们通常称之为单体应用；
• 架构单位应用的架构风格，我们称之为单体架构，这是一种比较传统的架构风格；

 单体架构存在的缺点：

• 复杂性逐渐变高；
• 技术债务逐渐上升；
• 部署速度逐渐变慢；
• 阻碍技术创新；
• 无法按需伸缩；

二、微服务

• Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用 Http 资源 API 这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅作最低限度的集中管理。

三、微服务具备的特性

• 1. 每个微服务可以独立的运行在自己的进程里；
• 2. 一系列独立运行的微服务共同构建起了整个系统；
• 3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能；比如：订单管理、用户管理等；
• 4. 微服务之间通过一些轻量的通信机制进行通信，例如，通过 REST API 或者 RPC 的方式进行调用；

四、微服务的优点 

• 易于开发和维护；
• 启动较快；
• 局部修改容易部署；
• 技术栈不受限；
• 按需伸缩；
• DevOps；

五、微服务带来的挑战

• 运维要求较高；
• 分布式的复杂性；
• 接口调整成本高；
• 重复劳动；

六、微服务设计原则

• 单一职责原则；
• 服务自治原则；
• 轻量级通信原则；
• 接口明确原则；

七、微服务架构如何拆分

       微服务架构倡导应用程序设计成多个独立、可配置、可运行、可微服务的子服务。

       服务与服务通讯协议采用 Http 协议，使用 restful 风格 API 形式来进行通讯，数据交换格式轻量级 json 格式通讯，整个传输过程中采用的是二进制，所以 Http 协议可以跨语言平台，并且可以可其他不同的语言进行相互的通讯，所以很多开放平台都采用 Http 协议接口。

1. 微服务把每一个职责单一功能存放在独立的服务中；

2. 每个服务运行你在单独的进程中；

3. 每个服务有自己独立的数据存储、实际上有自己独立的缓存、数据库、消息队列等资源；

八、微服务架构与 SOA 架构的区别

1. 微服务架构基于 SOA 架构，是从其演变过来的，继承 SOA 架构的优点，在微服务架构中除 SOA 架构中的 ESB 消息总线，采用 http + json (restful) 进行传输；

2. 微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情 (专注)，目的是提高效率，每个服务与服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级；

3. SOA 架构中可能会发生数据库存储共享，微服务强调每个服务都是单独数据库，保证每个服务与服务之间互不影响；

4. 项目体系特征，微服务架构比 SOA 架构更加适合于互联网公司敏捷开发、快速迭代版本，因为粒度非常精细；