微服务架构详解

微服务架构详解
      结合网络的资源，本文从微服务引入到概念，组织与技术框架，到具体的服务发现机制，API网关，服务通信方式，做了比较详细的图示总结。

微服务概念介绍

1.微服务与单体架构

        假设有一个用户信息管理系统，包含了注册、登录、信息维护、授权四个核心功能，如上图所示，使用单体架构时，所有的功能会被放在一起，而使用微服务架构时，它们可以被拆分成四个独立的服务

2.微服务定义

        此人为Netflix前架构总监，经历了Netflix从单体架构到微服务架构的演变，这里给出了他对微服务的定义，比较重要的三个地方
1)Loosely Coupled（松散耦合，不能强依赖，如果有个团队对其他团队的依赖很强，那么就不能称之为微服务）
2)Service Oriented architecture（服务面向的架构，他认为微服务本质上还是SOA，只不过是细化的SOA，更落地）
3)Bounded Context（有界上下文，术语是局部状态，这一点比较重要。就是说服务之间有边界，每个团队维护自己的数据源，无集中式的数据管理，所以每个团队可独立维护，可独立演化）

3.微服务的组织架构

传统的组织架构：
        一个产品需要产品团队、用户体验团队、研发专家团队、测试专家团队、DBA专家团队、运维专家团队等。这样会有两个问题，一个是沟通成本较大，另一个是反馈比较慢。
        对于为服务来说，这样就不太好了，因为每一个微服务都有自己专属的产品、研发、测试人员。团队成员围绕微服务进行不断的迭代开发。微服务不像项目，结束之后人员回到各自组织。微服务是可以一直存在的，因此人员也可以在微服务中长期保持合作关系，跨部门的沟通成本大大降低。
        为了契合微服务小、灵、快的特点，更提倡大家使用跨职能产品组织架构。
        这种组织架构的核心，是开发微服务的团队，应该负责微服务的设计、开发、测试、部署直至运行的全生命周期，形成一个完整的闭环。

4.微服务的技术架构

        这个体系按照请求接入，由外到内的顺序，将整体架构分为接入层、网关层、业务服务层、支撑服务层、平台服务层和基础设施层六层。
1)最外层是接入层，通过负载均衡接入请求到内部平台，这些请求既有外部互联网请求，也有公司内部其它系统的请求。
2)网关层是微服务架构的核心层，是业务层接收外部流量的屏障。1.对接入的流量进行反向路由。2.拦截所有的请求，通过横切的方式完成熔断、限流、安全认证等功能。3.对请求进行分类，例如内部网关、H5网关、图片网关。
3)第三层是业务服务层，我们常说的微服务就集中在这一层，这里包含了系统核心的业务逻辑。刚才已经详细讲过。基础层提供单一简单的基础服务，例如人员、订单、支付。聚合层则是将不同的基础层聚合在一起，完成复杂的业务处理。
4)支撑服务层提供非业务功能，以支撑业务服务层和网关层软件的正常运行。
5)平台服务层站在系统平台的角度上，处理系统发布、资源调度整合等功能
6)基础设施层与软件关系不大，主要是支撑系统需要的硬件资源

5.微服务的中台战略

        这是阿里巴巴提出的微服务中台战略，是马云在去欧洲参观了一个规模很小，但效率贼高的公司之后提出的。他把技术架构又分了业务前台，业务中台和技术中台。强调大中台，小前台， 强化“技术中台+业务中台”，中台肥沃，在这上面的业务生态才会更繁荣。业务应用更小更灵活，迭代能力变强，按照市场变化不断演化新应用出来

微服务相关技术详解

1.服务发现机制

        在一个分布式的系统当中，有很多服务系统。在一个大的互联网公司，可能会有几十甚至上百个服务系统。
这些服务当中，会有生产者，也会有消费者。那么这些消费者该如何去发现这些生产者呢？

        微服务架构下服务实例具有动态分配的网络地址，随着服务的自动扩展、故障和发布升级，导致服务实例的网络地址发生动态变更。因此，需要一种机制，支持服务消费者在服务提供者实例地址发生变更时，能够及时感知获取最新的地址，即服务发现机制。

        经过多年的业界实践，总结出三种服务发现模式。

（1）集中式LB

        传统基于LB的模式。
专门的LB，负载均衡器，使用硬件的F5负载均衡器、软件的Nginx负载均衡器。
        服务器上线后，向运维申请一个域名，运维会配这个负载均衡器，域名会指向这个后台的服务。
        LB上有所有的服务地址，消费者要去访问这个服务时，会通过DNS做域名解析，域名解析会解析到LB上，LB会根据域名负载均衡到后台的服务。
        缺点：LB挂了的话，那整个服务系统就无法访问了。
                  消费者申请调用服务器要穿透LB，会有性能损失。

（2）进程内LB

       把LB这个功能移到了应用的进程内。
       服务提供者会自动地以注册的方式注册到服务注册表上面，并且定期地发送心跳，告诉服务注册表我还活着。
       消费者用了一个客户端，客户端带有服务发现和负载均衡的功能，他会通过LB来调用后台的服务，LB会定期地同步服务注册表的服务信息。
       缺点：但是在多语言环境中，你必须为不同语言的消费者去开发不同的客户端，升级成本、多语言支持成本就比较高。

（3）主机独立进程LB

       也不是在客户端进程内的LB，而是在每个主机上部署一个LB。
       消费者要调用后台的服务，首先是调用本机的LB进程，这个进程会帮他做负载均衡和远程调用。
       优点：支持多语言，多语言可以灵活接入，不需要为每种语言去开发客户端。
       缺点：运维成本会比较高，在每台主机都部署了LB进程。

2.API网关

       想像一个情景：拆分成微服务后，出现大量的服务，大量的接口，使得整个调用关系乱糟糟的。经常在开发过程中，写着写着，忽然想不起某个数据应该调用哪个服务。或者写歪了，调用了不该调用的服务，本来一个只读的功能结果修改了数据……
       或者是客户来访问的时候，我们不希望他知道一些细节。 一种屏蔽内部细节的东西——网关。

       所以，微服务的调用需要一个把关的东西——网关。 在调用者和被调用者中间加一层网关，每次调用时进行权限校验。

       最外层是用户接入设备。
       有个负载均衡器，之后就是网关层，最后是我们内部的微服务。
       网关是无状态的，好处是可以部署很多，也不用怕单点。 系统的稳定性和可靠性

反向路由：当外部的请求进来的时候，怎么找到内部的具体的微服务。 将外部的请求转换为内部的具体的服务调用。

认证安全：企业的门卫 正常的访问 恶意的访问

限流熔断：突发大流量访问的时候，比如双十一。 如果内部服务没有好的限流熔断措施，很可能造成内部服务器的瘫痪。

**熔断：**当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应
**限流：**一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。

日志监控：外面的请求去访问我们内部的服务，她的所有的流量都要经过网关。可以在网关上，对所有的流量进行访问的审计，把访问的情况做日志保存起来。 分析这些日志，分析调用的性能情况，对整个流量情况进行监控。

3.网关实例——Zuul

网关的核心其实是Servlet层，运行在tomca容器中。

核心组件——ZuulFilter Runner 管理了Zuul内部所有的过滤器。

前置路由过滤器：前置加工，比如参数校验、限流、鉴权。请求进入的话，要先经过前置路由过滤器，比如我们对请求要进行日志处理，请求来了，请求要调用后台哪个功能，需要有个路由功能。

路由过滤器：找到目标服务并且进行调用。

后置路由过滤器：调用过后，响应回来。 事后处理。比如说日志、统计。

最特色的地方在这：灵活的路由、过滤功能。
       灵活的过滤链机制： 过滤器：Groovy脚本 可以动态插拔

灵活的过滤器上传加载机制
       开发完过滤器以后，编译以后把它上传到过滤器的存储数据库中，后台有poller，他会定期pull，看有没有更新的数据库。
有的话会把它上传到网关的过滤器目录当中。
       上面的过滤器文件管理器会定期地扫这个 目录，如果发现有新的过滤器，通过Filter Load加载到网关的Filter Runner当中，那这个filter就生效了。

各个filter之间共享一些信息，这是通过Request Context。

过滤链的流程抽出来：
       请求进来以后，先到“pre filters”，然后你也可以加一些自定义的filter ，然后到routing filters ，会去调用后台的微服务，响应回来后经过 ：post filters“，之后以 respond 的形式回到服务端。 错误信息会抛给 error filter

4.服务通信方式

       微服务的服务都是独立进程，服务之间的通讯的效率、稳定性等等关乎着系统是否能高效、稳定运行。常见的通讯方式有RPC及REST

（1）RPC

       远程过程调用，是一种内部封装了底层网络技术细节，调用远程机器上的程序就像是这些程序在本地的地址空间一样。

序列化与反序列化+网络通信

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码（反序列化）；
9）服务消费方得到最终结果。
RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。

（2）REST

​         REST即表述性状态传递（Representational State Transfer，简称REST），是一种软件架构风格。REST通过HTTP协议定义的通用动词方法(GET、PUT、DELETE、POST) ，以URI对网络资源进行唯一标识，响应端根据请求端的不同需求，通过无状态通信，对其请求的资源进行表述。

 Rest架构的主要原则：
网络上的所有事物都被抽象为资源
每个资源都有一个唯一的资源标识符
同一个资源具有多种表现形式(xml,json等)
对资源的各种操作不会改变资源标识符
所有的操作都是无状态的