Monolith(单体应用), 也称之为单体系统或者是 单体架构 。就是一种把系统中所有的功能、模块耦合 在一个应用中的架构方式。

也就是将所有的代码及功能都包含在一个WAR包中的项目组织方式。它的组成就是由 多个模块(所有资源)打成一个war包,运行在一个服务器上,也就是 一个进程去运行。典型的就是用SSM框架做的web项目,部署在tomact服务器上。

缺点:

技术选择难:

扩展难:不易进行功能扩展。

可靠性差

迭代困难  

跨语言程度差  

团队协作难

优点:

项目易于管理 

部署简单    

MicroService(微服务)架构, 是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。由一个或多个微服务组成。

那什么是微服务(分布式)?就是 将一个大的应用拆分成多个小的应用(微服务),这些小的应用相对独立,每个小的应用都有自己的容器(Tomcat),有自己的运行进程,这些小的应用通过网络协议(HTTP Rest)进行相互通信,所有的应用一起工作完成整个项目的业务。

每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。

系统中的各个微服务可被技术选项,独立开发,独立部署,独立运维,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。

优点:

方便局部扩展,团队协作方便

技术选型多样化

单个微服务的复杂性低,一个微服务就干一件事

单个微服务容易开发和维护

服务和服务之间相对松耦合

数据库选型多样化(分库)

当项目规模大,微服务整体来说性能好。。。

缺点:

微服务之间数据交互速度受网络影响

技术成本高

开发成本高,如分布式事务处理

整个项目总体来看,比较复杂

微服务的部署比较麻烦

这里给出一张图片,便于理解单体应用和微服务的区别:

单体到微服务 PPT 单体项目和微服务_java

那些技术栈来实现微服务呢?

一个微服务架构设计需要以下内容:

1.服务治理

2.服务注册

3.服务调用

4.服务负载均衡

5.服务监控

6.服务开发。。。

以上这些都有不同的技术去实现,比如:

服务治理:有阿里的dubbo,

服务注册:有ZooKeeper,Eureka

服务调用:有Rest、RPC,

服务开发:用SpringBoot、Spring、SpringMVC,

服务配置与管理有:阿里的Diamond

服务熔断器有:Hystrix、Envoy

服务负载均衡有: Ribbon、Nginx

服务接口调用(客户端调用服务的简化工具): Ribbon、 Feign

服务配置中心管理有:S pringCloudConfig、Chef

服务路由有(API网关): Zuul

服务监控有: Zabbix、Nagios、Metrics、Spectator

消息队列有: Kafka、RabbitMQ、ActiveMQ

全链路追踪有: Zipkin,Brave、Dapper

服务部署有: Docker、OpenStack、Kubernetes

数据流操作开发包有: SpringCloud Stream(封装与Redis,Rabbit、Kafka等发送接收消息)

事件消息总线有: Spring Cloud Bus

而目前较成熟的微服务架构就是阿里的dubbo以及Spring中的SpringCloud。这也是我们需要学习的。

微服务设计几大原则

1) AKF 拆分原则

单体到微服务 PPT 单体项目和微服务_microservices_02

2) 前后端分离原则

  • 前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前端的用户体验优化效果更好。
  • 分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。
  • 前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。

3) 无状态服务

4) 基于RestFul 的通信风格

  • 无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有现成的成熟方案 HTTPS 即可。
  • JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
  • 语言无关,各大热门语言都提供成熟的 Restful API 框架,相对其他的一些RPC 框架生态更完善。

微服务远程调用方式

1.RPC:

Remote Produce Call远程过程调用,是一个计算机通信协议。类似的还有RMI。 自定义数据格式,基于原生TCP通信,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型。

该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。说得通俗一点就是:A计算机提供一个服务,B计算机可以像调用本地服务那样调用A计算机的服务。

两个程序进行通讯,必须约定好数据传输格式。就好比两个人聊天,要用同一种语言,否则无法沟通。所以,我们必须定义好请求和响应的格式。另外,数据在网路中传输需要进行序列化,所以还需要约定统一的序列化的方式。

单体到微服务 PPT 单体项目和微服务_微服务_03

2.Http:

http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。

现在热门的Rest风格,就可以通过http协议来实现。

MVC、RPC、SOA、微服务架构之间的区别

1 MVC 架构

MVC 架构已经很熟悉了,就是一个单体架构。

代表技术:Struts2、SpringMVC、Spring、Mybatis 等。

2 RPC 架构

RPC(Remote Procedure Call):远程过程调用。它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议。   服务与服务之间隔离的,都是通过应用来触发。

代表技术:Thrift、Hessian 等。

3 SOA 架构

SOA(Service oriented Architecture):面向服务架构

ESB(Enterparise Servce Bus):企业服务总线,服务中介。主要是提供了一个服务与服务之间的交互。

ESB 包含的功能如:负载均衡,流量控制,加密处理,服务的监控,异常处理,监控告急等。

代表技术:Mule、WSO2

4 微服务架构

微服务就是一个轻量级的服务治理方案。

代表技术:SpringCloud、dubbo 等

单体到微服务 PPT 单体项目和微服务_单体到微服务 PPT_04

单体到微服务 PPT 单体项目和微服务_微服务_05