SpringCloud——01相关常识问题

1. 微服务架构介绍

1.1 单体架构

1）介绍

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

2）特点

        2.1 打包成一个独立的单元（导成一个唯一的jar包或者war包）

        2.2 会以一个进程的方式来运行

3）优点

        3.1 项目易于管理

        3.2 部署简单

4）缺点

        4.1 测试成本高

        4.2 可伸缩性差

        4.3 可靠性差

        4.4 系统迭代困难

        4.5 跨语言程度差

        4.6 团队协作难

1.2 微服务架构

        微服务是一种架构风格，一个大型的复杂软件应用，由一个或多个微服务组成，系统中的各个微服务可被独立部署各个微服务之间是松耦合的，每个微服务只关注完成一个任务并很好的完成该任务。

1.2.1 架构风格

        架构风格就是项目的一种设计模式。

常见的架构风格有：

1）基于客户端服务端的

2）基于组件模型的架构（EJB）

3）分层架构(MVC)

4）面向服务架构(SOA)

1.2.2 微服务的特点

1）系统是由多个服务构成

2）每个服务可以单独独立部署

3）每个服务之间是松耦合的。 服务内部是高内聚的， 外部是低耦合的。 高内聚就是每个服务只关注完成一个功能

1.2.3 微服务的优缺点

1）优点

        1.1 测试容易

        1.2 可伸缩性强

        1.3 可靠性强

        1.4 跨语言程度会更加灵活

        1.5 团队协作容易

        1.6 系统迭代容易

2）缺点

        2.1 运维成本过高， 部署数量较多

        2.2 接口兼容多版本

        2.3 分布式系统的复杂性

        2.4 分布式事务

2. 常见软件架构方式的区别

2.1 MVC架构

其实 MVC 架构就是一个单体架构。
代表技术： Struts2、 SpringMVC、 Spring、 Mybatis 等等。

2.2 RPC 架构

RPC(Remote Procedure Call)： 远程过程调用。 他一种通过网络从远程计算机程序上请求服务， 而不需要了解底层网络技术的协议。
代表技术： Thrift、 Hessian 等等

2.3 SOA 架构

SOA(Service oriented Architecture)：面向服务架构
ESB(Enterparise Servce Bus)：企业服务总线， 服务中介。 主要是提供了一个服务与服务之间的交互。
ESB 包含的功能如： 负载均衡， 流量控制， 加密处理， 服务的监控， 异常处理， 监控告急等等。
代表技术： Mule、 WSO2

2.4 微服务架构

微服务就是一个轻量级的服务治理方案。
代表技术： SpringCloud、 dubbo 等等

3. 微服务的设计原则

我们在设计微服务的时候，一般会遵循4个原则，AKF 拆分原则、前后端分离原则、无状态服务和RestFul 的通信风格。

3.1 AKF拆分原则

        业界对于可扩展的系统架构设计有一个朴素的理念，就是“通过加机器就可以解决容量和可用性问题”，

        对于一个规模迅速增长的系统而言， 容量和性能问题当然是首当其冲的。 但是随着时间的向前，系统规模的增长， 除了面对性能与容量的问题外， 还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。 而许多系统， 在架构设计时并未充分考虑到这些问题， 导致系统的重构成为常态， 从而影响业务交付能力， 还浪费人力财力！ 对此， 《可扩展的艺术》 一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方 （Scalability Cube） 。 这个立方体中沿着三个坐标轴设置分别为： X、 Y、 Z。

Y 轴(功能) —— 关注应用中功能划分， 基于不同的业务拆分

X 轴(水平扩展) —— 关注水平扩展， 也就是”加机器解决问题

Z 轴(数据分区) —— 关注服务和数据的优先级划分， 如按地域划分

3.2 前端分离原则

        前后端分离原则， 简单来讲就是前端和后端的代码分离， 我们推荐的模式是最好采用物理分离的方式部署， 进一步促使更彻底的分离。 如果继续直接使用服务端模板技术， 如： jsp，把 java、 js、 html、 css 都堆到一个页面里， 稍微复杂一点的页面就无法维护了。
前后端分离的好处：

1）前后端技术分离， 可以由各自的专家来对各自的领域进行优化， 这样前段的用户体验优化效果更好

2）分离模式下， 前后端交互界面更清晰， 就剩下了接口模型， 后端的接口简洁明了，更容易维护

3）前端多渠道集成场景更容易实现， 后端服务无需变更， 采用统一的数据和模型， 可以支持多个前端： 例如： 微信 h5 前端、 PC 前端、 安卓前端、 IOS 前端

3.3 无状态服务

        对于无状态服务， 首先说一下什么是状态： 如果一个数据需要被多个服务共享， 才能完成一笔交易， 那么这个数据被称为状态。 进而依赖这个“状态”数据的服务被称为有状态服务， 反之称为无状态服务。
        那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态， 表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务， 那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
        场景说明： 例如我们以前在本地内存中建立的数据缓存、 Session 缓存， 到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储， 让业务服务变成一个无状态的计算节点。 迁移后， 就可以做到按需动态伸缩， 微服务应用在运行时动态增删节点， 就不再需要考虑缓存数据如何同步的问题。

3.4 RestFul 的通讯风格