微服务

[lkzwc]

微服务

康威定律几乎就是微前端（准确来说是微服务架构）的理论基础了。它指出了组织架构越庞大，其系统间沟通成本越高的问题。而解决这一问题的有效手段就是，将大的系统拆分成一个个微小的，可以独立自治的子系统。一旦系统的依赖限制在了内部，功能上更加内聚，对外部的依赖变少，那么就能显著的减少跨系统之间的沟通成本了

• 让软件有生命力
• 让产品迭代平滑进行
• 巨石应用的解构【随着功能迭代、软件库更新、人员变动的日益庞大】

方案上跟使用 iframe 做微前端一样简单，同时又解决了 iframe 带来的各种体验上的问题。

什么时候需要它

• 旧的系统不能下，新的需求还在来
• 系统需要一套动态可插拔机制

常见的微服务

• alfa
• 乾坤
• 无界
• Micro App
• 飞冰

如何拆分

考虑当你单独打开这个APP时候可以独立完成功能服务提交的一套逻辑

为什么没用 IFrame

• Iframe是一种浏览器原生隔离的技术，隔离性无法被突破
• 浏览器刷新，Iframe的URL状态丢失，(Future State),前进按钮无效
• UI不同步
• 全局上下文完全隔离，数据同步难
• 速度慢

样式隔离

• Web Component中的Shadow Dom=>如果Dom在shadow构建??
• CSS Module使用前缀进行约定式规范=>存在兼容，全局性问题
• 动态样式表=>随着应用加载样式

JS 隔离

• JS沙箱

即在微应用bootstrap和mount两个生命周期之前分别搭载快照，然后当应用切出或者卸载的时候，回滚状态即可

微服务治理

微服务下，每个服务有多个实例，需要一种机制将各个服务的实例进行统一管理和监控

微服务发现

• 服务注册

各个服务将服务实力信息发送到注册中心，并提供心跳机制保障服务在线

• 服务发现

从注册中心获取服务队员的实例列表

负载均衡

一般配合服务发现一起使用，注册中心收到请求之后，会根据不同的负载策略将请求打到不同的服务上

• 轮训法
• 随机发
• 加权轮训
• 源地址哈希(同一个客户端每次请求都会映射到同一台服务器上,相对固定)

熔断限流

监控微服务的各项指标，打到阈值之后，自动切断该服务的调用，防止服务奔溃影响整个系统。