一、单体架构
- 一个归档包包含了应用所有功能的应用程序,我们通常称之为单体应用;
- 架构单位应用的架构风格,我们称之为单体架构,这是一种比较传统的架构风格;
单体架构存在的缺点:
- 复杂性逐渐变高;
- 技术债务逐渐上升;
- 部署速度逐渐变慢;
- 阻碍技术创新;
- 无法按需伸缩;
二、微服务
- 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 架构更加适合于互联网公司敏捷开发、快速迭代版本,因为粒度非常精细;