微服务选型与探讨.pptVIP

微服务选型与探讨 问题汇总 1.为什么微服务部署很少采用边缘方式CI? 2.宏观角度下微服务架构所适用的场景及运维？ 3.金融行业的微服务的标准如何制定比较合理？ 4..net core 微服务需要用到哪些技术？ 5..net core 微服务有哪些成功的案例？ 6、微服务与系统模块化的取舍？ 为什么选择微服务 S/N 对比点 微服务架构 单体架构 结论 1 上手难度 API 接口调用 数据库共享或本地程序调用 单体架构胜 2.1 开发效率（简单项目） 早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大 早期工作量小，随着项目规模和时间的推移，效率大幅度下降 单体架构胜 2.2 开发效率（复杂项目） 早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大 早期工作量小，随着项目规模和时间的推移，效率大幅度下降 微服务架构胜 3 系统设计（高内聚低耦合） 每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易 以包的形式对代码进行模块划分，控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起 微服务架构胜 4 系统设计（扩展性） 独立开发新模块，通过 API 与现有模块交互 在现有系统上修改，与现存业务逻辑高度耦合 微服务架构胜 5 需求变更响应速度 各个微服务组件独立变更，容易实施敏捷开发方法 需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败 微服务架构胜 6 系统升级效率 各个微服务组件独立升级，上手和开发效率高，影响面小 需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败 微服务架构胜 7 运维效率 大系统被拆分为多个小系统，部署和运维难度加大，但可以利用 DevOps 等方式将运维工作自动化 简单直接 单体架构胜 8 知识积累 微服务组件可以在新项目中直接复用，包括前端页面 一般以共享库的形式复用后台代码 微服务架构胜 9.1 硬件需求（简单项目） 一个系统需部署多个微服务，需要启动多个运行容器 整个系统只需要一个运行容器 单体架构胜 9.2 硬件需求（高要求项目） 按需为不同业务模块伸缩资源节点 为整个系统分配资源，导致冗余 微服务架构胜 10.1 项目成本（简单系统） 项目早期和后期，成本变化曲线平缓 项目早期成本低，后期成本大 单体架构胜 10.2 项目成本（复杂系统） 项目早期和后期，成本变化曲线平缓 项目早期成本低，后期成本大 微服务架构胜 11 非功能需求 为单独的微服务按需调优，甚至更换实现方式和程序语言 为整个系统调优，牵一发而动全身 微服务架构胜 12 职责、成就感 拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队 职责不明确，容易产生扯皮行为 微服务架构胜 13 风险 大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险 系统是一个整体，一荣俱荣，一损俱损 微服务架构胜 微服务架构与单体架构的对比 康威定律 Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967) 设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构 分布式服务组成的系统 按照业务而不是技术来划分组织 做有生命的产品而不是项目 Smart endpoints 和 dumb pipes（强服务个体和弱通信） 自动化运维（DevOps） 容错 快速演化 AKF可扩展立方 （Scalability Cube） X轴扩展 —— 关注水平的数据和服务克隆，也就是前文提到的“加机器解决问题” Y轴扩展 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分 Z轴扩展 —— 关注服务和数据的优先级划分，如分地域划分 整个扩展模型，用下图来表示，其中原点代表完全无扩展的状态 身份认证 用户、客户端、资源交互过程中的身份认证授权框架 服务注册 服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。 服务发现 服务调用方从服务注册中心找到自己需要调用的服务的地址。 负载均衡 服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。 服务网关 服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。 配置中心 将本地化的配置信息（properties, xml, yaml 等）注册到配置中