1.SOA是一种理念，它的主要特性--面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。但是，SOA并没有定义出具体的实现方式，目前有两套SOA理念的实现方式：中心化和去中心化，这两套架构并没有优劣之分，还是要针对企业的根本诉求。

      2.SOA中心化的实现方式就是ESB，ESB的根本诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以，ESB是中心化的，很重，有一定的逻辑，但它的确可以解决一些公用逻辑的问题。

     3.SOA去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。分布式服务框架，主要有dubbox、spring cloud，实现后端服务治理的功能。

  Spring Cloud是基于Spring Boot的一整套实现微服务的框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

     最重要的是，跟spring boot框架一起使用的话，会让你开发微服务架构的云服务非常好的方便。 Spring Cloud包含了非常多的子框架，其中，Spring Cloud Netflix是其中一套框架，由Netflix开发后来又并入Spring Cloud大家庭，它主要提供的模块包括：服务发现、断路器和监控、智能路由、客户端负载均衡等。

      Dubbo和Spring Cloud的比较可以从社区活跃度、架构完整度、文档质量三个方面进行比较。其中，在架构完整度方面，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。

Spring Cloud Netflix包括如下组件

1）Eureka，服务注册和发现，它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。Eureka是一种基于客户端的服务发现机制，服务发现的具体机制见后面说明。

2）Zuul，网关，所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求。

3）Ribbon，即负载均衡，Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。

4）Feign，服务客户端，服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。

5）Hystrix，监控和断路器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控、降级和断路器功能。降级包括屏蔽降级和容错降级，屏蔽降级是指不发起远程调用，直接返回空或抛出异常；容错降级是指非核心服务不可调用时，可以对故障服务做业务放通，保证主流程不受影响。

6）Hystrix Dashboard，监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。

7）Turbine，监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看。

4、接下来再细看一下微服务，它的典型特征包括--分布式服务组成的系统，按照业务而不是技术来划分组织，做有生命的产品而不是项目，智能化服务端点与傻瓜式服务编排，自动化运维，系统容错，服务快速演化。微服务就是要去ESB，把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的ESB，服务间轻通信，是比SOA更彻底的拆分。

5、微服务数量很大，客户端如何访问这些服务：在N个微服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括：提供统一服务入口，让微服务对前台透明；聚合后台的服务，节省流量，提升性能；提供安全，过滤，流控等API管理功能。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。API Gateway可以有很多广义的实现办法：

Nginx+Lua

SpringCloud Zuul

Mashape Kong

    一般用过Taobao Open Platform的就能很容易的体会，TAO就是API Gateway

6、微服务数量很大，而且一般每一个服务都是有多个拷贝来做负载均衡，那么服务发现是怎么做的呢？有两种方式，各有优缺点，基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

       服务端方式：优点是简单，所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

       客户端方式：优点是架构简单，扩展灵活，只对服务注册器依赖；缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

7、Dubbox，主要实现后端服务治理，它的基本原理跟阿里巴巴中台战略中提到的阿里分布式服务框架HSF的原理是一致的。

Dubbox调用关系说明：

0）服务容器负责启动，加载，运行服务提供者。

1）服务提供者在启动时，向注册中心注册自己提供的服务。

2）服务消费者在启动时，向注册中心订阅自己所需的服务。

3）注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4）服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5）服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控。

8、微服务不是免费的午餐，带来好处的同时，也带来一系列问题，需要一个专业的团队和平台来保障微服务架构的成功落地。

      微服务的优点：开发简单，技术栈灵活，服务独立无依赖，独立按需扩展，可用性高；微服务的缺点（挑战）：多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，性能监控。

9、对于大的互联网公司，微服务架构是血液，是习惯，每家公司都有自己的套路和架构，细节有不同，但是核心理念是通的。对于一般的公司而言，实践微服务有非常大的技术挑战，于是乎才有了这么多IT供应商考虑这里的商机。微服务比较适合未来有一定的扩展复杂度，且有很大用户增量预期的应用，其实就是新兴的互联网公司。创业初期，不可能买大量的机器或者很贵的机器，但是又必须考虑应对成功后的巨量的用户，微服务架构成了最好的选择。

10、微服务对我们的思考我觉得更多的是思维上的，对于微服务架构， 技术上不是问题，意识比工具重要。

11、一般提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。