微服务设计入门[优质ppt]

设计微服务架构需要掌握的可选知识
• 某种为部署微服务而设计的开发框架
• Java：SpringBoot、Dropwizard
• 常用微服务运维工具
• 服务自动负载均衡
• Consul • Eureka：基于AWS的服务负载均衡 • Nginx • HAProxy
• 日志、监控
• ELK： Elasticsearch/Logstash/Kibana • Zabbix
微服务设计入门
设计分布式系统的常识和最佳实践汇总
什么是微服务？
• 全称微服务架构：Microservices Architecture，缩写为MSA
• Mart百度文库n Fowler的定义：
• 微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服 务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运 行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构 建，并且能够被独立地部署在生产环境、预发布环境等。另外，应尽量 避免统一的、集中式的服务管理机制，对具体一个服务而言，应根据应 用上下文，选择合适的语言、工具对其进行构建。
微服务架构能带来的好处——解决重量级 通信机制的问题
• 常见的重量级通信机制
• 基于HTTP的各种RPC（远程过程调用）风格协议：SOAP/WSDL、XML-RPC、 JSON-RPC、Burlap、Hessian
• 二进制DO（分布式对象）风格协议：Java RMI/EJB、.NET Remoting
划分服务的原则是什么？
• 参考DDD中的设计策略“界定的上下文”（Bounded Context）， 划分出系统中不同的领域模型（上下文）
• 每一个领域模型拥有自己独立的数据库（或其他持久存储） • DDD中其他对于划分服务有参考价值的设计策略
• 上下文映射（Context Map） • 共享内核（Shared Kernel） • 客户-供应商（Customer-Supplier） • 顺从者（Conformist） • 防崩溃层（Anticorruption Layer） • 隔离通道（Separate Way） • 开放主机服务（Open Host Service）
• 一种RESTful API开发框架
• Java：Spring MVC、Play、Jersey、RESTEasy、CXF • .NET：ASP.NET Web API • Node.js：Express、Seneca & PM2 • Python：Django REST Framework、Flask • Ruby：Rails、Sinatra、Grape
• 无法做到无状态，水平扩展困难
• 无法实现线性水平扩展 • 难以做容量规划
微服务架构能带来的好处——解决集中式 服务管理机制的问题
• 常见集中式服务管理机制
• 企业服务总线（ESB） • Dubbo的服务注册中心 • 配置中心
• 集中式服务管理机制的问题
• 可伸缩性差，容易成为性能瓶颈 • 有可能出现单点故障 • 设计开发难度极高，因为要保证非常高的可用性（HA）
• 重量级通信机制的问题
• 紧耦合：服务器端API做改动后，客户端必须同时做改动、同时部署 • 互操作性差：客户端与服务器端常常需要使用相同的编程语言 • 可伸缩性差：尤其是SOAP、XML-RPC
设计微服务架构需要掌握的基础知识
• 领域驱动设计（DDD） • RESTful API的设计
• 以及深入理解HTTP协议
划分服务的原则是什么？
• 判断良好服务的标准
• 自身保持高内聚，有自己独立的领域模型（上下文） • 封装内部变化，通过API对外暴露功能
• 只有本服务自身的代码可访问本领域模型的数据库 • 其他系统只能通过本服务暴露的API间接访问本服务的数据
• 与其他服务保持松耦合，能够独立修改和部署
• 依赖本服务的其他系统不必同时修改和部署
微服务架构的几大特征
• 由一组小的服务组成一个完整的应用（或网站） • 每个服务围绕一个相对独立的业务领域（领域模型）构建 • 服务之间通过轻量级的通信机制互相沟通 • 完全去中心化 • 每个服务都可以独立部署 • 每个服务可以使用不同的编程语言实现
微服务架构和传统面向服务架构（SOA） 的区别
• 能够实现服务自治，可独立进化
• 同一个领域模型（上下文）之上可以有多个发布单元，但是只有 一个是服务
• 常见的发布单元划分方式：一个服务、一个定时任务、一个管理后台
微服务架构能带来的好处——解决传统单 块风格（monolithic style ）应用的问 题
• 单一发布单元，发布困难
• 可能需要停掉整个应用（或网站） • 每次发布耗时很长：发布上百台服务器、预发布环境大量的回归测
试 ……
• 对服务器硬件配置要求极高，垂直扩展困难
• CPU、内存、硬盘、网络带宽 ……
微服务架构能带来的好处——解决传统单 块风格（monolithic style）应用的问题
• 单一代码库，代码维护复杂
• 修改或新增代码，影响范围难以清晰估计 • 迭代周期很长，难以制定周期固定的迭代开发计划 • 对程序员的技能要求很高
• 单一发布单元，测试困难
• 设计开发测试用例需要考虑的问题太多，包括验收测试、回归测试、性 能测试
• SOA没有为服务如何划分提出具体指导 • SOA无法防止服务之间过度耦合 • SOA通常使用重量级的通信协议，例如 SOAP/WSDL • SOA中常常有集中式的服务管理机制，例如 UDDI、ESB • SOA未强调服务的独立部署 • SOA难以使用不同的编程语言实现 • SOA的性能和可伸缩性无法满足面向互联网大流量应用的需要
• 基于Docker的部署和服务编排
设计微服务架构需要解决的主要问题
• 划分服务的原则是什么？ • 服务之间选择何种轻量级的通信协议？ • 如何做到服务的独立部署？ • 如何确定该使用何种服务编程语言？如何控制多语言带来的复杂
度？ • 如何做到服务的去中心化？ • 如何解决大量微服务引入的运维成本？