工作总结

Posted 2021-01-12 tcals

一、微服务概念

http://www.importnew.com/17588.html

什么是微服务（概念）

         单体->SOA->微服务

1、单体

单体->一个WAR包

        

优先：

开发简单直接，集中式管理

基本不会重复开发

功能都在本地，没有分布式管理的开销和调用通信开销

缺点：

开发效率低：所有开发都在一个项目上改代码，代码冲突

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

部署不灵活：构建不灵活，必须重新构建整个项目，时间长

稳定性不高：一个小问题可能搞挂整改应用

扩展性不够：无法满足高并发，新增功能必须重新构建、部署整改应用

2、SOA

没有去中心化，基于模块化的应用拆分，应用的交互依赖服务总线、

中间件服务器比如数据库、ETCD等独立的中间件进程为集群式部署、且服务端的信息相互共享不隔离。

 

3、微服务

真正分布式的，去中心化的SOA，服务之间的不实例相互隔离，比如ETCD、数据库实例是相互隔离的。把服务内的逻辑封装在自己内部，把路由、消息解析放在服务内部，服务间轻量级通信（HTTP、跨进程的Global RPC）。

简单来说，微服务的目的是有效拆分应用，实现敏捷开发和部署。

 

 

1. 一些列的独立的服务共同组成系统
2. 单独部署，跑在自己的进程里
3. 每个服务为独立的业务开发
4. 分布式的管理

 

4、怎么实践微服务

1）如何访问这么多拆分的微服务？

APIGateway：

提供统一的服务入口，让服务对前台透明

聚合后台的服务，节省流量，提升性能

提供安全、过滤、流控等管理功能

 

2）服务之间如何通信？

同步调用（REST、RPC），我们现在REST也支持异步调用。实现简单、兼容性好

异步消息调用（Kafka,RMQ），消息有缓存、通信上来说存在弱一致

 

3）服务怎么找？

注册中心（etcd或者zk做服务信息的分布式管理），服务可在本地做缓存，服务变更通知客户端。

提供寻址算法（负载均衡）

客户端做：架构简单，扩展灵活，只对注册中心依赖。大公司

服务端做：优化是简单，所有服务对于前台调用方透明。小公司。

 

4）这么多服务，挂了怎么办？

雪崩、调用链太长一个挂了 导致服务整个调用链不可用。

手段：

重试机制

限流

熔断机制

负载均衡

降级（本地缓存）

 

5）微服务需要考虑的问题

API Gateway

服务间调用

服务发现

服务容错

服务部署

数据调用

 

优缺点：

优点

    开发简单

    技术栈灵活

    服务独立无依赖

    独立按需扩展

    可用性高

缺点

    多服务运维难度

    系统部署依赖

    服务间通信成本

    数据一致性

    系统集成测试

    重复工作

    性能监控

 

6）我们的架构和应用

提供最精简的karaf容器底座

提供微服务打包的开发模板

提供微服务的restful通信开发模板

提供进程间通信（restful、rpc）的调用框架

二、微服务进程间通信

服务自动发现，注册，上下线更新

关联技术：websocket

 

服务性能（本地缓存优化）

1）注册时建立服务的依赖关系，以及class访问时与path的对应关系，path与实例的映射，实例自动缓存在本地，这样class访问时自动映射到实例地址

2）服务实例变更通知，采用disruptor框架将消息广播出去，便于其他业务获取服务信息

关联技术：缓存方式设计、disruptor框架

 

服务路由的负载均衡

用户自由扩展路由策略

         关联技术：反射

服务可靠性

注册中心容错、服务的容错熔断

服务间通信

1）流程：

Swagger生成开发模板->

请求方式从restful调用转换为API调用->

反射获取服务的API实例->

框架将API注解扫描，并解析出注解上的Path加入本地缓存->

调用API的方法，找到请求的方法对应的Path->

然后通过path和class信息找到实例地址->

然后调用转换为HTTP请求发送过去。

关联技术：反射

 

2）通信方式（REST、RPC）

         关联技术：同步REST、异步REST（jetty client、jetty server）

        

         3）序列化反序列化

         关联技术：fastxml.jackson 不同序列化框架的性能对比，工作原理，为什么快？

        

最终一致性

事件通知型（可靠事件通知型（同步事件、异步事件）、最大努力通知模式）

补偿型（TCC模式、业务补偿）

 

三、Jetty

Jetty架构

Jetty的原理

Jetty热加载等其他特性

关联技术：java NIO机制、HTTP1.1/HTTP2协议、servlet机制

 

四、Jersey

原理

序列化反序列化

关联技术：servlet机制、javax-ws-rs协议、反射、序列化框架

五、WebApp统一鉴权框架

注册原理

优化

Servlet规范和原理

关联技术：servlet机制、osgi机制、jetty api使用

六、性能数据上报

上报流程

上报优化（报文合并分批上报）

关联技术：kafka、优化思路

 

七、大容量——restful异步、HTTP2

Jetty httpclient 异步

Jetty server 异步

Jersey异步

Jetty对HTTP2协议实现