什么是单体应用？什么是微服务？

Monolith（单体应用）， 也称之为单体系统或者是 单体架构 。就是一种把系统中所有的功能、模块、组件等耦合在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署，通常一个应用享用一个数据库。
也就是将所有的代码及功能都包含在一个WAR包中的项目组织方式。它的组成就是由 多个模块（所有资源）打成一个war包，运行在一个服务器上，也就是 一个进程去运行。典型的就是用SSM框架做的web项目，部署在tomact服务器上。

在单体应用中我们通常把应用分为三个组成部分：持久层，业务层，表现层.

单体应用在数据量，并发量到一定程度的时候一定会遇到瓶颈.
缺点：

• 对于高并发、大数据量 ，处理不占优势
• 开发时间越长，代码越多，项目越臃肿，杂乱无章
• 模块与模块，业务与业务耦合高 ：比如一个模块挂了，其他模块也挂，一个模块升级，其他模块也要重启
• 技术选型单一，数据库选型单一
• 项目体积庞大的时候，会造成，编译慢，项目打包等也慢。
• 二次开发，维护难
• 新的程序员对项目需要花很长时间去熟悉，成本高。
• 不方便局部拓展，只能整体做集群

优点：

• 项目初期，项目的搭建，开发都比较快

• 技术成本低，对程序员的要求相对低 ， 开发成本较低

• 项目的部署相对简单 - 就一个tomcat

MicroService(微服务)架构， 是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。由一个或多个微服务组成。
那什么是微服务(分布式)？就是 将一个大的应用拆分成多个小的应用(微服务)，这些小的应用相对独立，每个小的应用都有自己的容器(Tomcat)，有自己的运行进程，这些小的应用通过网络协议(HTTP Rest)进行相互通信，所有的应用一起工作完成整个项目的业务。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。
系统中的各个微服务可被技术选项，独立开发，独立部署，独立运维，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
优点：

• 方便局部扩展，团队协作方便
• 技术选型多样化
• 单个微服务的复杂性低，一个微服务就干一件事
• 单个微服务容易开发和维护
• 服务和服务之间相对松耦合
• 数据库选型多样化(分库)
• 当项目规模大，微服务整体来说性能好。。。

缺点：

• 微服务之间数据交互速度受网络影响
• 技术成本高
• 开发成本高，如分布式事务处理
• 整个项目总体来看，比较复杂
• 微服务的部署比较麻烦

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

 

上面说到技术成本高，那么需要 那些技术栈来实现微服务呢？
一个微服务架构设计需要以下内容：

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 拆分原则

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

 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 等