什么是微服务?

简而言之，微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。

最大的好处就是可拔插，可扩展性好吧，一个APP可能由不同的小服务组件组成。

关键是服务的粒度，以前SOA提供的服务太大，可复用率不高。谓服务讲究更小的粒度，就如同乐高一样，本身不需要更改，依靠合成来提供业务服务。这其中的难点，一是性能，一是业务拆解。

许多功能不是拧在一块儿了，而是分裂成一个个的服务。 一个个的服务可以在一台机器上，也可以在不同的机器上。
我的理解就是REST。比如你需要哪个功能就发一个REST请求给那个服务，服务接收完你的请求就会去处理，处理完了再返回给你。这样有个好处就是解耦合了。一个服务坏掉不会影响另一个。 在Java里，微服务还可以解决jar包冲突的问题。想一想几百个jar包放在一起，冲突的可能性是不是很大？分开来就好了。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化。
后面的请参考
https://www.zhihu.com/question/37808426

什么是微服务?

举个简单的例子，做一个用户管理项目，里边就三个功能：用户注册、用户登录、用户详情浏览。按照传统的软件开发方式直接创建一个Web项目，分分钟就把这三个功能开发出来了，但是我现在想使用微服务+服务治理的方式来开发：首先我将这个项目拆分为四个微服务，四个微服务各建一个模块，分别是用户注册模块、用户登录模块、用户详情浏览模块和数据库操作模块，这四个模块通过内部服务治理互相调用。但是现在存在一个问题，这四个模块通过服务注册与订阅的方式互相依赖，如果一个模块出现故障会导致依赖它的模块也发生故障从而发生故障蔓延，进而导致整个服务的瘫痪。比如说这里的登录模块依赖于数据库模块，如果数据库模块发生故障，那么当登录模块去调用数据库模块的时候可能得不到响应，这个调用的线程被挂起，如果处于高并发的环境下，就会导致登录模块也崩溃。当一个系统划分的模块越多，这种故障发生的频率就会越高，对于这个问题，Spring Cloud中最重要的解决方案就是断路器，那么本文我们就来看看什么是断路器。

首先我们分别启动服务注册中心，再启动两个服务提供者的实例，端口号分别是8080和8081，然后再启动一个服务消费者，服务消费者的端口号为9000，这几个都启动成功之后，我们访问http://localhost:9000/ribbon-consumer这个地址，可以看到如下效果：Spring Cloud中的断路器Hystrix-博客-云栖社区-阿里云 https://yq.aliyun.com/articles/293633