微服务架构的4个核心问题
- 服务很多, 客户端该怎么访问?
- 这么多服务, 服务之间如何通信?
- 这么多服务, 如何治理?
- 服务挂了怎么办?
解决方案
SpringCloud生态 SpringBoot
- SpringCloud NetFlix 一站式解决方案undefinedapi网关 zuul组件 Feign ---HttpClinet ---Http通信方式同步阻塞 服务注册与发现: Eureka 熔断机制: Hystrix
- Apache Dubbo Zookeeper 半自动需要整合别人的 api网关 没有 找第三方组件, 或者自己实现 Dubbo Zookeeper 没有借助 Hystrix
Dubbo 这个方案并不完善~
- SpringCloud Alibaba 一站式解决方案 更简单
新概念 服务网格~Serve Mesh
istio
万变不离其宗
- API网关
- HTTP RPC
- 注册和发现
- 熔断机制
网络不可靠!
常见面试题
- 什么是微服务
- 微服务之间是如何建立通信的
- SpringCloud和Dubbp有哪些区别
- SpringCloud和SpringBoot请谈谈你对他们呢得理解
- 什么服务熔断? 什么是服务降级
- 微服务得优缺点是什么? 说下你在项目开发中遇到的坑
- 你所知道的微服务技术有哪些? 列举一二
- eureka和zookeeper都可以实现提供服务注册与发现功能, 请说明两个的区别?
微服务概述
什么是微服务
什么是微服务？（熟悉的同学可以直接跳过）
简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下：
- 部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
- 改动影响大，风险高（不论代码改动多小，成本都相同）
- 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
- 当然还有例如无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题，但我们不一一详谈了，以上的问题，都是微服务架构要解决的问题，至于具体是怎么解决的，我们先放到后面再聊
https://martinfowler.com/articles/microservices.html
微服务与微服务架构
微服务
强调的是服务的大小, 它关注的是某一点, 在具体解决某一问题/提供落地对应服务的一个服务应用, 侠义的看, 可以看作是IDEA中的一个个微服务工程, 或者Moudel
- IDEA工具里面使用Maven开发的, 一个个独立的Moudel, 它具体使用springboot开发的一个模块, 专业的事情交给专业的模块来做, 一个模块就做一个事情
- 强调的是一个个的个体, 每个个体完成一个具体的任务或者功能
微服务架构
一种新的框架形式, Martin Fowler 2014年提出
微服务框架是一种框架模式, 它提倡将单一应用程序化为一组服务, 服务之间相互协调, 互相配合, 为用户提供最终价值. 每个服务运行在其独立进程中, 服务于服务间采用轻量级的通信机制相互协作, 每个服务都围绕着具体业务来构建, 并且能够独立部署到生产环境中, 另外, 尽量避免统一的, 集中式的管理机制. 对于一个具体服务而言, 应根据服务上下文, 选择合适的语言工具进行构建.
微服务的优缺点
优点:
- 这种单体架构的优点在于方便管理，所有代码在同一项目中，但是当需求越来越多，项目规模越来越大，其坏处也很明显。
- 单一职责原则
- 每个服务足够内聚, 足够小, 代码容易理解, 这样能够聚焦一个指定的业务功能或业务需求
- 开发简单, 开发效率高, 一个服务就是专一的只干一件事情
- 微服务可以被小团队开发, 这个小团队是2-5人开发人员组成
- 微服务是松耦合的, 具有功能意义的服务, 无论是在开发阶段还是在部署阶段
- 微服务可以使用不同语言开发
- 易于和第三方库集成, 微服务允许容易灵活的方式自动部署, 通过持续集成工具, 如Jenkins Hudson bamboo
- 微服务允许你利用融合最新技术
- 微服务只是逻辑代码, 不会和html css或其他界面混合
- 每个微服务都有自己的存储能力, 可以有自己的数据库, 也可以有一些数据库
缺点:
- 开发人员需要处理分布式系统的复杂性
- 多服务运维难度, 随着服务增加, 运维压力也在增加(运维压力增大)
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
- 项目过于臃肿，部署效率低下
当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次非常耗时。
- 系统高可用性差，资源无法隔离 整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
- 开发成本高 早期在团队开发人员只有两三个人的时候，协作修改代码，打包部署，更新发布这完全可以控制。但是团队一旦扩张，还是按照早期的方法去开发，那如果测试阶段只要有一块功能有问题，就得重新编译打包部署。所有的开发人员又都得参与其中，效率低下，开发成本极高。
- 无法灵活拓展 当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：
为什么选择SpringCloud作为微服务框架
选型依据
- 整体解决方案和框架的成熟度
- 社区热度
- 可维护性
- 学习曲线
当前各大IT公司用的微服务框架有哪些
- 阿里: dubbo HFS
- 京东: JSF
- 新浪: Motan
- 当当网: DubboX
- ...
各微服务框架对比
文章已上传gitee https://gitee.com/codingce/hexo-blog
项目地址: https://github.com/xzMhehe/codingce-java
