微服务概念

1.什么是微服务？

        顾名思义，是一个微小的服务，为什么会说是“ 微 ” 呢？

        意思整个服务的是比较微小的，是一个独立的业务模块，专做改业务的事情，是一个独立的功能单元。

        一种独特的架构设计模式，它将是软件、web 或移动应用拆分为一系列独立的服务 —— 如微服务。这些服务仅用于某一个特定的业务功能，例如：用户管理、用户角色、电子商务购物车、搜索引擎、社交媒体登录等。此外，它们是相互独立的，这意味着它们可以采用不同的编程语言和数据存储。微服务中几乎不存在集中管理，它使用轻量级的HTTP 、 REST 来进行内部通信 。

2.RPC 

       RPC(Remote Process Call)：远程服务调用，被广泛地应用在很多企业应用中，是早期主要的 服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider， provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成。

3.SOA

SOA(Service-Oriented Architecture)，即面向服务的架构。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。

阿里巴巴的 Dubbo 是SOA的典型实现。

4.服务治理方案

        业界的互联网巨头公司，都有属于自己的分布式服务框架，如阿里巴巴的Dubbo ， HSF ，腾讯的Tars，京东的 JSF ，新浪的 Motan ，都已经是业界非常成熟的解决方案，其中开源的 Dubbo 和 Motan 受 到了广大开发者的研究对象。

        纵观这些服务框架，设计的基本思路都如上图，无非涉及provider 发布注册， consumer 订阅，调用发起，负载均衡，服务分流和监控等模块，并在此基础上增加了很多玩法，形成了各具特色的分布式服务框架设计，下面就Dubbo ， JSF ， Motan 的设计做下简单的介绍

5. 分布式服务框架主要模块名词释义

1. Provider：服务提供者，无论是业务服务，还是一个系统中公用的SAAS，都属于Provider。
2. Consumer：服务消费者，即发起调用的客户端。
3. Registry：服务注册中心，是分布式服务系统中的一个重要组成模块，管理Provider的Manager，在实际的运行环境中，服务注册中心Registry被动通知或Consumer主动询问，在Provider有节点宕机或新增节点时，客户端也可实时感知到，从而避免了某个Provider被无限调用或是无限闲置。
4. Gateway： 网关也是分布式服务框架中不可或缺的部分，每种系统与框架都有自己的一套协议，当异构系统互相调用时，网关的作用即显现出来，Gateway接受各种外部HTTP请求，完成相应的权限校验，报文适配，路由转发到对应的Provider，再将Provider返回的结果传递给异构系统的Consumer，完成异构系统的互相调用。
5. 负载均衡：服务分流: Consumer 从 Registry 获得具体的 Provider 列表后，如何选取合适的Provider，取决与一定的负载均衡算法，常见的算法有轮询法，随机法，源地址哈希，加权轮询，加权随机等。
6. 监控：接收来自 Consumer 和 Provider 异步上报的性能监控数据，对有风险的节点发出告警。

6.SOA架构

        随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，迫切需一个治理系统确保架构有条不素的演进。

• 单一应用架构：当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
• 垂直应用架构：当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相千的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
• 分布式服务架构：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐新形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
• 流动计算架构：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

常用实现远程通信的方案：

1. Webservice:效率不高基于soap协议。项目中不推荐使用。
2. 使用restful形式的服务: http+json。很多项目中应用。如果服务太多，服务之间调用关系混乱，需要治疗服务。
3. 使用dubbo/dubbox。使用rpc协议进行远程调用，直接使用socket通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。

 

7.Dubbox简介

        Dubbox是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo,被国内电商及互联网项目中使用，后期阿里巴巴停止了Dubbo项目的维护 (现Dubbo已捐献给Apache基金会)，因为阿里巴巴内部的HSF框架比Dubbo更高效，更贴合他们业务。当当网便在Dubbo基础上进行优化，并继续进行维护，为了与原有的Dubbo区别，故将其命名为Dubbox。

8.Dubbox作用

        Dubbox 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说dubbox就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。

9.Dubbox运行流程

 

0.服务容器负责启动，加载，运行服务提供者.
1.服务提供者在启动时，向注册中心注册自己提供的服务。
2.服务消费者在启动时，向注册中心订阅自己所需的服务。
3.注册中心返回服务提供者地址列表给消费者，如果有变更，注册心将基于长连接推送变更数据给消费者。
4.服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5.服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控
中心。

10.注册中心zookeeper

        一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如: 统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

CAP原则

1. C(consistency)一致性：同一时刻的同一请求的实例返回结果相同，属于强一致性，也就是说，在集群环境中，对外提供的服务信息是完全一致的，但是在效率上面可能会有一定的损耗;
2. A(availability)可用性：所有实例的读写请求在一定的时间内可以得到正确的响应，它是弱一致性，可能在极短的时间内，不同实例获取到的信息是不一致的，但是服务可用并且最终数据是一致的;
3. P(Partition tolerance)分区容错性：在网络异常的情况下，仍旧能够提供正常的响应，这是在微服务系统中必须要保证的;

特点分析-Zookeeper
优势、特性

• 成熟协调系统，dubbo，Spring cloud均可适配
• CP模型，数据强一致性
• 提供简单配置管理
• 社区活跃度中

不足

• 不提供控制台管理 (可使用第三方开源管理)
• 维护成本较高，客户端，session状态，网络故障等问题，会导致服务异常