微服务架构

 

转自：https://www.cnblogs.com/imyalost/p/6792724.html

概念

是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持

单体架构和微服务架构的区别

单体架构

优点

开发简单，集中式管理

基本不会重复开发

功能都在本地，没有分布式的管理和调用消耗

缺点

效率低：开发都在同一个项目改代码，相互等待，冲突不断

维护难：代码功功能耦合在一起，新人不知道何从下手

不灵活：构建时间长，任何小修改都要重构整个项目，耗时

稳定性差：一个微小的问题，都可能导致整个应用挂掉

扩展性不够：无法满足高并发下的业务需求

微服务架构

优点

开发简单

技术栈灵活

服务独立无依赖

独立按需扩展

可用性高

缺点

多服务运维难度

系统部署依赖

服务间通信成本

数据一致性

系统集成测试

如何具体实现微服务

四点问题：

1. 客户端如何访问这些服务?
2. 每个服务之间如何通信?
3. 如此多的服务，如何实现?
4. 服务挂了，如何解决？

客户端如何访问这些服务？

API Gateway：提供统一服务入口，让微服务对前台透明聚合后台的服务，节省流量，提升性能提供安全，过滤，流控等API管理功能

每个服务之间如何通信?

同步调用：

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

异步消息调用:

• Kafka
• Notify
• MetaQ

同步和异步的区别：

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。

一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的

SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，

他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的

服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息

发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

如此多的服务，如何实现?

 

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。

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

 

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

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

服务挂了，如何解决？

 

前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，

不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

①重试机制

②限流

③熔断机制

④负载均衡

⑤降级（本地缓存）

这些方法基本都很明确通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix