微服务入门

尚未施工完成

1. 什么是微服务？

微服务架构是一种架构概念，旨在经过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要做用是将功能分解到离散的各个服务当中，从而下降系统的耦合性，并提供更加灵活的服务支持。

2. 微服务的历史

说到微服务，就要说说这个老头，他是一个英国人，叫作Martin Fowler，后面移居了美国。 虽然他不是微服务概念的最先提出者，不过不少人都是经过他和James Lewis的文章了解微服务的概念。

这是他2014年发布的文章 martinfowler.com/articles/mi…

而微服务最先的提出是2012年，是这个家伙说的，就是上面和Martin Flower合做出了文章的James Lewis。 James Lewis是ThoughtWorks的首席顾问，也是技术顾问委员会的成员。

俺寻思这人也是个神人，为了写这篇文章，就用谷歌和维基搜了一下，谁知道他这么没有牌面，只有推特以及上面那篇文章找到一个头像及简介。

3. 传统架构与微服务架构的区别

开发模式

在传统的开发模式中，咱们将全部功能打在一个 WAR 包内，基于三层架构和 MVC 来对应用进行解耦，并部署在一个 JavaEE 容器中。咱们能够方便的对其进行集中式管理，与微服务架构相比，由于全部功能都在本地，因此功能间没有通讯的问题。

单体架构

微服务架构

咱们能够看出，微服务架构经过将复杂单体应用进行细粒度的拆分，能够分别部署成不一样的服务。再将功能模块解耦后，不只能够下降单独服务器的压力，由于都是独立拆分出来的服务，也能实现独立部署独立开发。

这样的好处显而易见，拆分后的服务交给不一样团队独立维护，进行分布式管理，彼此间不须要太多的顾忌，这样能让咱们实现更方便的代码维护工做，同时开发时放心使用新的技术，而没必要担忧由于一个服务的故障使整个应用没法使用。

4. 微服务的实践

客户端如何访问这些服务

每一个服务之间如何通讯

同步调用

• REST（JAX-RS，Spring Boot）
• RPC（Thrift, Dubbo）

异步消息调用

• Kafka
• Notify
• MessageQueue

如何实现？

基于客户端的服务注册与发现

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

基于服务端的服务注册与发现

优势是简单，全部服务对于前台调用方透明，通常在小公司在云服务上部署的应用采用的比较多。

服务挂了，如何解决？

前面提到，Monolithic 方式开发一个很大的风险是，把全部鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。经过微服务拆分能下降这个风险，不过若是没有特别的保障，结局确定是噩梦。因此当咱们的系统是由一系列的服务调用链组成的时候，咱们必须确保任一环节出问题都不至于影响总体链路。相应的手段有不少：

• 重试机制
• 限流
• 熔断机制
• 负载均衡
• 降级（本地缓存

聚合器微服务设计模式

异步消息传递微服务设计模式

这是一个Spring Cloud Netflix 方案的 demo github.com/unkoe/hello…