微服务--学习笔记

l  单体应用

与微服务相对的概念--单体式应用程序。

单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。，例如Hello word程序。

集成，功能集中化，牵一发动全身、开发/测试/部署/维护问题

优点：	1.开发简洁，功能在单个程序内部，便于软件设计和开发规划 2.容易部署，程序单一不存在分布式集群的复杂部署环境，降低部署难度 3.容易测试，没有各种复杂的服务调用关系，都是内部调用方法测试
缺点：	1.不利于目前需求快速变更的时代，即变更会带来很多问题； 2.软件维护，迭代成本高； 3.扩展性不好，整体扩展，即扩展时以应用程序为单位(例如，单个业务模块负载过高时，无法单独扩展改服务，必须扩展整个应用程序，导致资源浪费)； 4.单体应用由于服务之间的紧密度、相互依赖性过高——导致测试、升级困难，且开发曲线有可能会在后期大幅度上升(比较之下，微服务可解决该问题)。

l  微服务

微服务，Micriservices就是一些协同工作小而自治的服务(微服务可以理解为SOA面向服务架构的一种变体)。轻量化、服务以业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模集中管理(例如，Docker)能力，服务可使用不同编程语言与数据库等组件实现。

微服务优点：

优点	说明
技术异构性	不同服务你把开发技术可不一致(例如用java开发A服务，C#开发B服务)；不同的部分也可以使用不同的存储技术，例如A服务可选择redis存储，B服务选择Sqlserver存储。你的服务你做主
隔离性	一个服务不可用不会导致一个服务也瘫痪，各服务相互独立和自治。
可扩展性	和单体服务整体应用扩展不同，可进行单个服务升级扩展
简化部署	各服务部署相互独立，影响单个自身服务，出问题可快速回滚版本解决
易优化	微服务代码量、代码结构相对单体应用--代码量小、结构简单，易优化
插件化	抽象、提取、插件化

 

微服务缺点：

缺点	说明
服务插件化	服务插件化导致，管理问题(人多手杂)

其他特点：

1)        抽象、提取、插件化

2)        服务公平化

3)        微服务是SOA的一种变体

4)        分解隔离--持久化层

5)        影响数据库--拆分

6)        积木效应--服务间调用

7)        链路跟踪--服务内部调用关系

8)        网关--按业务领域将微服务分区，区内直接调用，区间通过网关调用

9)        冗余--一个服务多实例部署，分担压力，提高性能。操作方式：

部署新实例、将新实例注册到负载均衡或DNS上。

10)     熔断、服务降级、限流

熔断--多次访问，未果标记服务停止；

服务降级--例如淘宝上推荐模块出问题，下单模块应不受影响

限流--自我保护策略(例如，服务刚恢复，没有限流，可能导致瞬间大量访问，可能导致再次服务崩溃)

11)     ELK，日志分析组件

Elasticsearch，搜索引擎、LogStash,日志采集器、Kibana,UI组件

12)     测试

端到端测试：覆盖整个系统，一般在用户界面机型测试

服务测试：针对服务接口测试

单元测试：针对代码单元进行测试

13)     Mock server 模拟服务器

14)     升级问题

耗时，常年稳定的服务负责人可能拒绝更细，应完善版本管理方法，开发管理规范

15)     Server mesh

服务网格，反向代理，不入侵代码，升级维护便捷，性能问题--内存拷贝的额外成本等。反向代理组件Sidecar不会产生额外网络成本。Sidecar会和微服务节点部署在同一台主机上并且共用相同的虚拟网卡。所以sidecar和微服务节点的通信实际上都只是通过内存拷贝实现的。

              Sidecar只负责网络通信。还需要有个组件来统一管理所有sidecar的配置。在Service           Mesh中，负责网络通信的部分叫数据平面（data plane），负责配置管理的部分叫                控制平面（control plane）。数据平面和控制平面构成了Service Mesh的基本架构。

              被认为是下一代微服务架构，用于解决其他工具已经解决过的网络调用、限流、熔              断和监控等问题，只不过是在cloud native的kubernates环境下的实现

       特点：

              应用程序间通讯的中间层、轻量级网络代理、应用程序无感知、解耦应用程序的重试/超时、监控、追踪和服务发现。

16)     负载均衡

负载均衡，英文名称为Load Balance，其含义就是指将负载（工作任务）进行平衡、分摊到多个操作单元上进行运行，例如FTP服务器、Web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

其他说明：

1. 服务注册与发行

微服务之间相互调用完成整体业务功能，如何在众多微服务中找到正确的目标服务地址，这就是所谓「服务发现」功能。

常用的做法是服务提供方启动的时候把自己的地址上报给--服务注册中心(即，服务注册)。服务调用方订阅服务变更通知，动态的接收服务注册中心推送的服务地址列表，后续使用服务直接发生即可。

 

1. 服务监控

包括：拓扑关系、监控Metrics、日志监控Logging、调用追踪Trace、告警通知、监控检测等，防患于未然。

1. 服务容错

宕机、过载——需要引入，熔断、隔离、限流和降级、超时机制等机制来保证服务持续可用性。

1. 服务安全

敏感服务采用安全鉴权机制，对服务的访问需要进行相应的身份验证和授权，防止数据泄露的风险。

1. 服务治理--微服务框架--来帮助我们进行服务治理(服务多等问题)
2. 常见微服务框架

名称	描述
Dubbo	阿里巴巴公司开源的一个Java高性能优秀的服务框架,仅支持Java
Tars	腾讯内部使用的微服务架构TAF--Total Application Framework,仅支持C++
Motan	新浪微博开源的一个java框架，仅支持Java
gRPC	Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于Protobuf序列号协议开发。本身不是分布式的，支持多种语言。
Thrift	最初Facebook开发的内部系统跨语言的高性能RPC框架，2007年贡献给Apache基金，称为Apache开源项目之一，和gRPC一样，Thrift也有一套自己的接口定义语言IDL,可以通过代码生成器，生成各种编程语言的Client端和Server段的SDK代码，支持多种语言

1. RPC

Remote Procedure Call远程过程调用是一个计算机通信协议。一般的程序调用是本地程序内部的调用，RPC运行你像调用本地函数一样调用另一个程序的函数，这中间会设计网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。RPC是一种服务器-客户端模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

RPC、微服务

微服务框架是一套软件开发框架，包含了RPC的实现和一系列服务治理能力。

l