微服务设计入门

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