微服务是商业应用程序开发中最热门的新事物。微服务这个词取代了敏捷、DevOps和RESTful，成为了所有简历和大会演讲中都必须提及的新热门词。

微服务这一概念出现于2012年，因敏捷开发方法创始人之一的Martin Fowler而流行，微服务架构是一项在云中部署应用和服务的新技术。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通。”关键在于该服务可以在极致的程序中运行。

微服务作为一项云中部署应用和服务的新技术，已成为当下最新的热门话题。大部分为稍微服务的争论都集中在容器或其他技术是否能够很好地实施微服务。企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中，微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件，它们可以更加容易升级和拓展。

让我们回到上世纪80年代初，第一种重要的系统分发技术"远程过程调用(RPC)"诞生的时候。RPC是Sun Microsystems最初的ONCRPC背后的设想理念，也是DCE（1988年）和CORBA（1991年）背后的基本理念。

我们使用Enterprise JavaBeans(EJBs)实现了第一个Session Facade，尽管仅在Java中使用时很有效，但它很复杂，难以调试，而且无法与其他语言或其他供应商产品互操作。缺乏互操作性直接导致我们在2000年代初期到中期开展了下一项工作：该工作成果后来以面向服务的架构(SOA)而闻名。但是，SOA最初没有采用这个高端大气的术语。它最初始于一次"以最简单方式实现目标"的尝试，获得的成果就是Microsoft最初在1999年发布的简单对象访问协议(SOAP)。

围绕SOAP进行的初期工作很有帮助，这一点很快得到证明，人们可以轻松地合并使用许多不同语言和在许多不同平台上实现的系统。但SOA在整体上的败笔是，它脱离了简单的初衷，开始添加一层又一层脱离了简单方法调用的一些附加概念：添加了异常处理、事务支持、安全性和数字签名，人们感觉SOA已经变成了一个复杂协议。

使用EJB、SOAP和其他复杂分发技术的团队最终发现，尝试让分布式系统看起来像本地系统最终会带来苦果。最后，Fowler围绕分散化治理和分散化数据管理的规定源于一项来之不易的发现：您的程序和运行时环境应自给自足。

在Netflix和Amazon等公司发布大量成功案例后，微服务架构开始引起关注。

微服务的另一个重要方面，微服务涉及到称为DevOps的一组实践的操作端。这个方面源于最初为传统应用程序管理而开发的许多模式。Fowler在其最初的微服务论文中强调了这方面的重要性，他指出有必要在基于持续交付和持续集成原则构建的DevOps流程中适应基础架构的自动化。

正因如此，许多常见的框架（比如用于微服务的Netflix框架和Amalgam8）都在适应Service Registry模式：通过避免将特定的微服务端点硬编码到您的代码中，不仅可以更改下游微服务的实现，还可以在DevOps管道的不同阶段中选择不同的服务位置。如果没有Service Registry，随着对代码的更改开始沿一个微服务调用链向上传播，您的应用程序很快将会陷入困境。

Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. It also allows the architecture of an individual service to emerge through continuous refactoring. Microservice-based architectures facilitate continuous delivery and deployment.

单体架构Monolithic：

1. 单个Java WAR文件。
2. 单个Rails或者NodeJS代码目录层级。

单体架构比较适合小项目，优点是：

1. 开发简单直接，集中式管理
2. 基本不会重复开发
3. 功能都在本地，没有分布式的管理开销和调用开销

它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：

1. 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
2. 代码维护难：代码功能耦合在一起，新人不知道何从下手
3. 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
4. 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
5. 扩展性不够：无法满足高并发情况下的业务需求

对于单块架构的优缺点概括如下：
优点有：易于开发、测试（模式易于理解，并且有成熟的开发工具能够使用）；易于部署和水平伸缩（只需把对应的软件包复制到配置好运行环境的节点即可）。
不足有：维护成本增加（随着应用程序功能越来越多，团队越来越大，相应的沟通成本、管理成本、人员协调成本必然会显著增加）；持续交付周期长（代码逐渐复杂之后，构建和部署的时间也会相应增加）；新人培养周期渐长；技术选型成本高（初始的技术选型严重限制了将来采用不同语言或框架的能力。如果想尝试新的编程语言或框架，没有完备的功能测试集，很难平滑完成替换，而且系统规模越大，风险越高）；可扩展性差（不论是垂直扩展还是水平扩展，其代价都会比较高）；构建全功能团队难（这种开发模式在分工时往往以技能为单位，这将导致任何功能上的改变都可能需要跨团队的沟通和协调）。

微服务架构：

具体实现手段：

1. 单独的数据库，如果该微服务的数据量比较大，需要分库分表。
2. 统一的服务接口，尤其是使用了API网关
3. 所有的微服务都是独立的Java进程跑在独立的虚拟机上

要解决的技术难点：

1、这么多服务，怎么找?

通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

2、服务之间如何通信？

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式

3、这么多服务，服务挂了怎么办？

相应的手段有很多：
重试机制
限流
熔断机制
负载均衡
降级（本地缓存）

这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：Netflix/Hystrix

作为服务注册中心，Eureka比Zookeeper好在哪里

著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

Zookeeper保证CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

相关资料：

小草：技术分享|微服务模式发展简史​zhuanlan.zhihu.com

https://blog.csdn.net/u012422829/article/details/68947350​blog.csdn.nethttps://blog.csdn.net/m0_37707170/article/details/82253058​blog.csdn.netLean Work：微服务，敏捷开发方法的关键​zhuanlan.zhihu.com

赵云：Eureka的工作原理以及它与ZooKeeper的区别​zhuanlan.zhihu.com

https://blog.csdn.net/m0_37707170/article/details/82253058​blog.csdn.net