微服务和微服务架构
- 一、什么是微服务
- 二、微服务架构中要面临的几个问题
- 2.1 客户端如何访问这些服务
- 2.2 每个服务之间如何通信
- 2.3 如何解决服务发现的问题
- 2.4 服务挂了如何解决
- 三、一些和微服务相关的概念区分
- 3.1 SOA和微服务的区别
- 3.2 分布式服务
声明：本文章非完全原创，文中很多知识源于网络，整理出来完全是为了便于自己的学习。源于
微服务始于哪年？何人提出？历史背景？我没有考证，爱八卦的同学可以深挖?。
一、什么是微服务
了解什么是微服务之前，需要了解什么是Monolithic（单体式开发）。单体式开发就是所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。
这种开发框架优缺点也显而易见。项目初期，预估服务的使用量和并发量都不大，这种框架也未尝不可。
针对单体式开发的缺点，出现的新技术就叫微服务（Microservice ）。微服务是啥？简单来说微服务就是把臃肿的单体式服务框架做分解，分解成很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。
二、微服务架构中要面临的几个问题
2.1 客户端如何访问这些服务
原来的单体式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？
后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。
另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无 状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。
所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
用过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。
2.2 每个服务之间如何通信
所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：
同步调用(rest，rpc)：
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
thrift: 跨语言的rpc框架，facebook贡献
dubbo: 国内较早开源的服务治理的Java rpc框架，虽然在阿里巴巴内部竞争中落败于HSF，沉寂了几年，但是在国内得到了广泛的应用，目前dubbo项目又获得了支持，并且dubbo 3.0也开始开发
rest 和 rpc 都是网络交互的协议规范。通常用于多个微服务之间的通信协议。
比较项 规范 | REST | RPC |
通信协议 | HTTP | 一般使用TCP |
性能 | 低 | 高 |
灵活度 | 高 | 低 |
建议：REST调用及测试都很方便，RPC就显得有点繁琐，但是RPC的效率是毋庸置疑的，所以建议在多系统之间的内部调用采用RPC。对外提供的服务，Rest更加合适。
异步消息调用(Kafka, Notify, MetaQ)
2.3 如何解决服务发现的问题
在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？
这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息
注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。
当服务下线时，ZK会发通知给服务客户端。
客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。
服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。
2.4 服务挂了如何解决
前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，
不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：
①重试机制
②限流
③熔断机制 ：玩股票的同学可能比较清楚。熔断机制（Circuit Breaker），也叫自动停盘机制，是指当股指波幅达到规定的熔断点时，交易所为控制风险采取的暂停交易措施?。在微服务架构中，熔断机制是指如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
④负载均衡：它是利用一个集群中的多台单机，完成许多并行的小的工作。一般情况下，如果一个应用使用的人多了，那么用户请求的相应时间就会增大，机器的性能也会受到影响，如果使用负载均衡集群，那么集群中任意一台机器都能相应用户的请求，这样集群就会在用户发出服务请求之后，选择当时负载最小，能够提供最好的服务的这台机器来接受请求并相应，这样就可用用集群来增加系统的可用性和稳定性。
常见方案又DNS负载均衡、ngnix反向代理负载均衡
⑤降级（本地缓存）
这些方法基本都很明确通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
三、一些和微服务相关的概念区分
3.1 SOA和微服务的区别
1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
3.2 分布式服务
顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
微服务是架构设计方式，分布式是系统部署方式，两者概念不同.
注：分布式需要做好事务管理。
分布式事务可参考：微服务架构的分布式事务解决方案
3、集群部署
集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。区别集群的方式是根据部署多台服务器业务是否相同。
注：集群模式需要做好session共享，确保在不同服务器切换的过程中不会因为没有获取到session而中止退出服务。
一般配置Nginx*的负载容器实现：静态资源缓存、Session共享可以附带实现，Nginx支持5000个并发量。
