微服务总结

微服务架构的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