微服务 Microservice
2018-07-02 14:16:35 0 举报AI智能生成
微服务
作者其他创作
大纲/内容
传统的web开发方式
特点
所有功能打在一个war包里
基本没有外部依赖（除了容器）
部署在一个JEE（Tomcat，JBoss，WebLogic）容器里
包含了DO/DAO，Service，UI等所有逻辑
优势
开发简单直接，集中式管理
基本不会重复开发
功能都在本地，没有分布式管理开销和效用开销
劣势
开发效率低
所有的开发在一个项目上改代码，递交代码互相等待，代码冲突不断
代码维护难
代码功能耦合在一起，新人不知道从何下手
部署不灵活
构建时间长，任何小修改必须重新构建整个项目
稳定性不高
一个微不足道的小问题，可以导致整个应用挂掉
扩展性不够
无法满足高并发情况下的业务需求
微服务（Microservice）
特点
一系列的独立的服务共同组成系统
单独部署，跑在自己的进程里
每个服务为独立的业务开发
分布式的管理
按照业务而不是技术划分组织
vs SOA
Microservice是SOA的传承
Microservice是分布式的，去中心化的，去除了ESB（业务总线）
把所有的“思考”逻辑包括路由、消息解析等放在服务内部
去掉一个大一统的ESB，服务间轻通信
比SOA更彻底的拆分
HOW
客户端如何访问这些服务？
API Gateway
提供统一服务入口，让微服务对前台透明
聚合后台服务，节省流量，提升性能
提供安全，过滤，流控等API管理功能
服务之间如何通信？
同步调用
方式
REST（JAX-RS）
RPC（Dubbo）
特点
简单，一致性强
调用层次多的时候，性能低，容易出错
RESTful vs RPC
RESTful
基于HTTP
更容易实现
各种语言都支持
跨客户端
RPC
传输协议更高效
安全更可控
异步消息调用
常见产品
Kafka
Notify
MetaQ
特点
减低调用服务之间的耦合
成为调用之间的缓冲，确保消息挤压不会冲垮调用方
保证调用方的体验，不阻塞
一致性弱
后台服务一般要实现幂等性，防止消息重复
保证消息仅接收一次对性能是很大的考验，一般实现幂等
必须引入独立的broker
broker，消息代理，一般使用消息中间件，如ActiveMQ
这么多服务，怎么找？
使用zookeeper等类似技术做服务注册信息的分布式管理
客户端做
优势
架构简单
扩展灵活
只对服务注册器依赖
劣势
客户端要维护所有调用服务的地址
Dubbo
服务端做
优势
简单
所有服务对于前台调用方透明
服务挂了怎么办？
重试机制
限流
熔断机制
一般是指软件系统中，由于某些原因出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施
也称为 过载保护
负载均衡
降级
方式
延迟服务
关闭服务
跳转
写降级
如秒杀，值进行Cache更新，然后异步同步扣减库存到DB，保证最终一致性即可
读降级
如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，适用于对读一致性要求不高的场景
优势
开发简单
技术栈灵活
服务独立无依赖
独立按需扩展
可用性高
劣势（挑战）
多服务运维难度
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
重复工作
性能监控
互联网公司 vs 一般公司
互联网公司
微服务架构是血液，是习惯，每家公司都有自己的套路和架构，细节有不同，核心理念是通的
一般公司
实践微服务有非常大的技术挑战
比较适合未来有一定的扩展复杂度，且有很大的用户增量预期的应用
0 条评论
下一页
