微服务设计入门

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