微服务设计入门

微服务架构能带来的好处——解决传统单 块风格（monolithic style）应用的问题
• 单一代码库，代码维护复杂
• 修改或新增代码，影响范围难以清晰估计 • 迭代周期很长，难以制定周期固定的迭代开发计划 • 对程序员的技能要求很高
• 单一发布单元，测试困难
• 设计开发测试用例需要考虑的问题太多，包括验收测试、回归测试、性 能测试
• 基于Google Protocol Buffer数据交换格式的各种RPC协议 • 基于Apache Thrift协议的各种RPC协议，例如唯品会的OSP
• 不建议选择基于HTTP的RPC协议
• 紧耦合 • 可伸缩性差
如何确定使用何种服务编程语言？
• 优先选择团队原先掌握的编程语言 • 选择另外一种互补性强的编程语言
划分服务的原则是什么？
• 判断良好服务的标准
• 自身保持高内聚，有自己独立的领域模型（上下文） • 封装内部变化，通过API对外暴露功能
• 只有本服务自身的代码可访问本领域模型的数据库 • 其他系统只能通过本服务暴露的API间接访问本服务的数据
• 与其他服务保持松耦合，能够独立修改和部署
• 依赖本服务的其他系统不必同时修改和部署
微服务的反模式——饕餮（Gluttony）： 使用过多的通信协议
• 现象：
• 使用了很多通信协议：HTTP、Protobuf、gRPC、Thrift、AMQP、MQTT
• 解决方法
• 尝试对于通信协议进行标准化
• 选择一种同步通信协议，例如 JSON over HTTP（RESTful API） • 选择一种异步通信协议，例如 RabbitMQ（AMQP）。
• 优点：不需要做大量的运维工作、控制力度强、可移植性好 • 缺点：学习成本较高
不同团队看待微服务的不同视角
• 产品设计团队视角
• 更大的灵活性 • 更强的响应力
• 开发团队视角
• 更便于维护 • 更便于增量迭代式开发 • 更容易测试 • 上线回归时间更短
• 测试团队视角
• 运维团队视角
• 更好的可伸缩性、高可用性 • 更容易部署 • 更容易监控
如何控制多语言带来的复杂度
• 在一个机构内，限制编程语言的数量
• 服务编程语言限制在两种以内 • 客户端编程语言限制在两种以内
• 建立统一的服务API设计风格
• 例如各种语言都很容易实现的RESTful API
如何做到服务的独立部署？
• 尽量减少服务之间的依赖
• 服务功能做到高内聚
• API设计做到松耦合
• 验收测试、回归测试、性能测试
• 负载均衡自动化 • 扩容、缩容自动化 • 监控自动化
• 基于Docker容器部署 • 基于云计算平台部署
基于Docker容器部署带来的好处
• 可以提高部署的自动化程度
• 缩短部署时间，达到秒级部署
• 可以提高测试环境与生产环境的一致性
• 在测试环境中测出尽量多与环境有关的bug
• 一种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
• 基于Docker的部署和服务编排
设计微服务架构需要解决的主要问题
• 划分服务的原则是什么？ • 服务之间选择何种轻量级的通信协议？ • 如何做到服务的独立部署？ • 如何确定该使用何种服务编程语言？如何控制多语言带来的复杂 度？ • 如何做到服务的去中心化？ • 如何解决大量微服务引入的运维成本？
• 基于通用的通信机制，首选基于HTTP的RESTful API • 服务API可做的独立修改
• • • • • 可自由添加非必需的请求参数 可自由修改请求参数的类型 可自由添加响应参数 可自由添加错误代码 可通过超文本通知客户端相关联的资源
• 通过服务版本号控制不兼容的修改
如何做到服务的去中心化？
设计微服务架构需要掌握的可选知识
• 某种为部署微服务而设计的开发框架
• Java：SpringBoot、Dropwizard
• 常用微服务运维工具
• 服务自动负载均衡
• • • • Consul Eureka：基于AWS的服务负载均衡 Nginx HAProxy
• 日志、监控
• ELK： Elasticsearch/Logstash/Kibana • Zabbix
• Docker、 Kubernetes、Terraform，这些技术固然很好，并非一定要立即使用
• 解决Baidu Nhomakorabea法：
• • • •
应该鼓励组织创建自己的策略，决定何时应用这些创新技术 在IT行业没有银弹：不要相信最新、最牛x的技术能够解决你们所有的问题 定义并深入理解你要解决的问题，是非常重要的 调查你有哪些选项，创建文档清晰地分析采用各种选项的理由、需求、产出， 这可以帮助你做决策 • 深入思考架构、人员的技能评估、以及你的业务目标 • 选择落后技术没什么丢人，只要这些技术能很好地解决问题
• 普通场合应优先选择基于HTTP的RESTful API
• • • • • 基于HTTP协议，互操作性好，各种编程语言都支持 可伸缩性好 松耦合 易于测试 易于形成统一的编程风格
服务之间选择何种轻量级的通信协议？
• 在特殊场合可以选择二进制的RPC协议
• 对低延迟、实时性要求极高 • 服务的API极少变化，因此松耦合不重要 • 可选的二进制的RPC协议：
• SOA没有为服务如何划分提出具体指导 • SOA无法防止服务之间过度耦合 • SOA通常使用重量级的通信协议，例如 SOAP/WSDL • SOA中常常有集中式的服务管理机制，例如 UDDI、ESB • SOA未强调服务的独立部署 • SOA难以使用不同的编程语言实现 • SOA的性能和可伸缩性无法满足面向互联网大流量应用的需要
微服务架构的几大特征
• 由一组小的服务组成一个完整的应用（或网站） • 每个服务围绕一个相对独立的业务领域（领域模型）构建 • 服务之间通过轻量级的通信机制互相沟通 • 完全去中心化 • 每个服务都可以独立部署 • 每个服务可以使用不同的编程语言实现
微服务架构和传统面向服务架构（SOA） 的区别
• 重量级通信机制的问题
• 紧耦合：服务器端API做改动后，客户端必须同时做改动、同时部署 • 互操作性差：客户端与服务器端常常需要使用相同的编程语言 • 可伸缩性差：尤其是SOAP、XML-RPC
设计微服务架构需要掌握的基础知识
• 领域驱动设计（DDD） • RESTful API的设计
• 以及深入理解HTTP协议
微服务系统的团队管理
• 康威定律（Conway’s Law）
• 任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案 在结构来说，都会与 该组织的沟通结构 保持一致。
• 必须有整体的规划和相关规范
• 划分界定的上下文 • 根据界定的上下文划分服务 • 制定并维护服务设计规范、监控规范
微服务系统的团队管理
微服务架构能带来的好处——解决重量级 通信机制的问题
• 常见的重量级通信机制
• 基于HTTP的各种RPC（远程过程调用）风格协议：SOAP/WSDL、XML-RPC、 JSON-RPC、Burlap、Hessian • 二进制DO（分布式对象）风格协议：Java RMI/EJB、.NET Remoting
• 无法做到无状态，水平扩展困难
• 无法实现线性水平扩展 • 难以做容量规划
微服务架构能带来的好处——解决集中式 服务管理机制的问题
• 常见集中式服务管理机制
• 企业服务总线（ESB） • Dubbo的服务注册中心 • 配置中心
• 集中式服务管理机制的问题
• 可伸缩性差，容易成为性能瓶颈 • 有可能出现单点故障 • 设计开发难度极高，因为要保证非常高的可用性（HA）
微服务和云计算平台结合
• 微服务和IaaS（基础设施即服务）结合
• 优点：很容易提高硬件配置、自己可以完全控制、可移植性好 • 缺点：自己需要做大量的运维工作
• 微服务和PaaS（平台即服务）结合
• 优点：不需要做大量的运维工作、 • 缺点：控制力度很弱、可移植性差
• 微服务和CaaS（容器即服务）结合
划分服务的原则是什么？
• 参考DDD中的设计策略“界定的上下文”（Bounded Context）， 划分出系统中不同的领域模型（上下文） • 每一个领域模型拥有自己独立的数据库（或其他持久存储） • DDD中其他对于划分服务有参考价值的设计策略
• • • • • • • 上下文映射（Context Map） 共享内核（Shared Kernel） 客户-供应商（Customer-Supplier） 顺从者（Conformist） 防崩溃层（Anticorruption Layer） 隔离通道（Separate Way） 开放主机服务（Open Host Service）
• 可以提高服务器硬件资源的利用效率 • 可以实现自动化扩容、缩容
基于云计算平台部署带来的好处
• 可以带来更好的可伸缩性
• 水平扩展、垂直扩展都更容易
• 可以带来更好的容错性 • 可以很容易地添加各种新的能力
• 例如阿里云所支持的大数据分析工具
• 可以大幅降低运维的成本
• 与应用无关的系统级运维，由云计算平台运营商负责 • 应用的运维团队只需关注与应用本身相关的运维
• Java/C# 与 Node.js/Python/Ruby/Go
• 根据对性能的要求
• 性能要求高：Java/C#/Node.js/Go • 性能要求不高：Python/Ruby
• 根据业务逻辑的变化频繁程度
• 业务逻辑相对固定：Java/C# • 业务逻辑可能经常变化：Node.js/Python/Ruby
微服务架构能带来的好处——解决传统单 块风格（monolithic style ）应用的问题
• 单一发布单元，发布困难
• 可能需要停掉整个应用（或网站） • 每次发布耗时很长：发布上百台服务器、预发布环境大量的回归测试 ……
• 对服务器硬件配置要求极高，垂直扩展困难
• CPU、内存、硬盘、网络带宽 ……
微服务设计入门
设计分布式系统的常识和最佳实践汇总
主讲人：李锟
什么是微服务？
• 全称微服务架构：Microservices Architecture，缩写为MSA • Martin Fowler的定义：
• 微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服 务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运 行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构 建，并且能够被独立地部署在生产环境、预发布环境等。另外，应尽量 避免统一的、集中式的服务管理机制，对具体一个服务而言，应根据应 用上下文，选择合适的语言、工具对其进行构建。
• 团队组织应与划分的领域模型（上下文）匹配
• 产品设计团队 • 开发团队 • 测试团队
• 充分授权
• 让小团队完全拥有某个领域模型及其上服务的所有权 • 所有权涵盖需求、构建、部署、运维等服务的全生命周期
微服务的反模式——纵欲（Lust）：使用 最新的、最牛x的技术
• 现象：
• 总是喜欢使用最新的、最牛x的技术 • Design by Buzzword • 使用最适合目标、问题或需求用例的技术
• 不使用集中式的企业服务总线或服务注册中心
• 通过域名+URL来暴露服务 • 使用Consul+DNS来做服务发现和自动负载均衡
• 不使用集中式的配置中心
• 配置信息由每个服务自行管理
• 案例分析：2010年淘宝网的配置中心服务
如何解决大量微服务引入的运维成本？
• 能自动化的地方一定尽量自动化
• 发布自动化 • 测试自动化
• 能够实现服务自治，可独立进化
• 同一个领域模型（上下文）之上可以有多个发布单元，但是只有 一个是服务
• 常见的发布单元划分方式：一个服务、一个定时任务、一个管理后台
服务之间选择何种轻量级的通信协议？
• API的实现技术应该避免产生与客户端的耦合
• 例如Java RMI，要求客户端必须使用Java语言，耦合很强 • 应该选择与具体技术不相关的API实现方式，以保证技术的选择不被限制