微服务

微服务

一、微服务设计原则
1.AKF拆分原则
AKF拆分原则 业界对可扩展系统架构设计有一个朴素的概念，就是：通过加机器可以解决容量和可用性问题（如果一台不行就两台）
用个段子描述就是：（世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿）

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

（1）Y轴功能Y轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能。
（2）X轴（水平扩展）
X轴扩展与我们前面理念是一致的。通过绝对平等的复制服务与数据，以及容量和可用性问题。
（3）Z轴（数据分区）
Z周扩展通常是指基于请求和用户独特的需求，进行系统划分，并使得划分出来的子系统相互隔离，但又是完整的

2.前后端分离
1.前后端分离与不分离的区别
（1）前后端不分离
在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。
（2）前后端分离
在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中 ，前端与后端的耦合度相对较低。
在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。

3.无状态服务
1.所谓状态，是指程序在执行过程中生成的中间数据，而无状态容器，是指容器在运行时，不在容器中保存任何数据，而将数据统一保存在容器外部，比如数据库中。
因为有状态的容器异常重启就会造成数据丢失，也无法多副本部署，无法实现负载均衡。
2.定义：无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。
3.劣势：
有状态服务常常用于实现事务。举一个常见的例子，在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的，所以为了实现有状态服务，就需要通过一些额外的方案。比如最常见的session，将用户挑选的商品（购物车），保存到session中，当付款的时候，再从购物车里取出商品信息
有状态服务可以很容易地实现事务，所以也是有价值的。但是经常听到一种说法，即server要设计为无状态的，这主要是从可伸缩性来考虑的。如果server是无状态的，那么对于客户端来说，就可以将请求发送到任意一台server上，然后就可以通过负载均衡等手段，实现水平扩展。如果server是有状态的，那么就无法很容易地实现了，因为客户端需要始终把请求发到同一台server才行，所谓“session迁移”等方案，也就是为了解决这个问题 。
4.session和cookie ：基于session和cookie都可以实现事务，可以认为，session是有状态的，而cookie是无状态的。
5.有状态服务可以比较容易地实现事务，在不需要考虑水平扩展时，是比较好的选择
无状态服务的优势在于可以很方便地水平伸缩，但是在实现事务时，需要做一些额外的动作 ，可以通过剥离session等方法，将一个有状态服务，转换成无状态服务。
4.Restful通信风格
1.概念: 一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。
2.原则条件REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
在服务器端，应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体，它向客户端公开。资源的例子有：应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口，以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法，比如 GET、PUT、POST 和 DELETE。Hypermedia 是应用程序状态的引擎，资源表示通过超链接互联。
3.RESTFUL特点包括：
1、每一个URI代表1种资源；
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源；
3、通过操作资源的表现形式来操作资源；
4、资源的表现形式是XML或者HTML；
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。
二、微服务带来的问题
1.依赖服务接口变更
2.部分模块重复构建
3.分布式带来的问题

1. 分布式系统中的缓存
2. 缓存和DB的数据不一致
3. 缓存扩容：一致性Hash算法
4. 分布式下的Session问题
5. 数据库读写分离，数据复制延迟。
6. 负载均衡算法实现

4.运维复杂度陡增

三、微服务架构的好处
1.它解决了复杂性的问题。它将一个可怕的、庞大的整体应用分解成一组服务。在整体的功能没有改变的同时，应用程序已经被分解成可管理的模块或服务
2.这种架构使得每个服务可以由单独的团队独立开发，这些团队可以专注于某个服务。开发者可以自由地选择合理的技术，只要服务遵守 API 约定即可。当然大部分组织想要避免混乱地完全无限制的技术选择。然后这种自由意味着开发者不在受限于使用可能过时的技术开始新的项目。
3.微服务架构模式使得每一个微服务能被独立部署。开发者再也不需要调整本地对其服务的更变而进行部署。各种类型的变更能在他们测试时立即部署。UI 团队也可以这样做，举例来说，当 UI 发生改变时，能执行 A|B 测试并快速迭代。微服务架构模式让持续部署成为可能。
4.微服务架构模式使得每一个服务都可以被独立扩展。你可以部署大量恰好符合要求容量和有效约束条件的服务实例。
四、微服务相关技术Docker
1.Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
2.优点
（1）无论是安装应用、搭建环境，还是部署应用，都十分的方便灵活。
（2）节省资源开销。
（3）灵活的迁移你开发的应用程序。
3.Docker 的主要用途，目前有三大类。
（1）提供一次性的环境。比如，本地测试他人的软件、持续集成的时候提供单元测试和构建的环境。
（2）提供弹性的云服务。因为 Docker 容器可以随开随关，很适合动态扩容和缩容。
（3）组建微服务架构。通过多个容器，一台机器可以跑多个服务，因此在本机就可以模拟出微服务架构。