微服务设计入门设计分布式系统的常识和最佳实践汇总主讲人：李锟什么是微服务？全称微服务架构：MicroservicesArchitecture，缩写为MSAMartinFowler的定义：微服务架构是一种架构模式，它提倡将单一应用程序划分为一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署在生产环境、预发布环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体一个服务而言，应根据应用上下文，选择合适的语言、工具对其进行构建。微服务架构的几大特征由一组小的服务组成一个完整的应用（或网站）每个服务围绕一个相对独立的业务领域（领域模型）构建服务之间通过轻量级的通信机制互相沟通完全去中心化每个服务都可以独立部署每个服务可以使用不同的编程语言实现微服务架构和传统面向服务架构（SOA）的区别SOA没有为服务如何划分提出具体指导SOA无法防止服务之间过度耦合SOA通常使用重量级的通信协议，例如 SOAP/WSDLSOA中常常有集中式的服务管理机制，例如 UDDI、ESBSOA未强调服务的独立部署SOA难以使用不同的编程语言实现SOA的性能和可伸缩性无法满足面向互联网大流量应用的需要微服务架构能带来的好处解决传统单块风格（monolithic style）应用的问题单一代码库，代码维护复杂修改或新增代码，影响范围难以清晰估计迭代周期很长，难以制定周期固定的迭代开发计划对程序员的技能要求很高单一发布单元，测试困难设计开发测试用例需要考虑的问题太多，包括验收测试、回归测试、性能测试微服务架构能带来的好处解决传统单块风格（monolithic style ）应用的问题单一发布单元，发布困难可能需要停掉整个应用（或网站）每次发布耗时很长：发布上百台服务器、预发布环境大量的回归测试 对服务器硬件配置要求极高，垂直扩展困难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.NETWebAPINode.js：Express、Seneca & PM2Python：DjangoRESTFramework、FlaskRuby：Rails、Sinatra、Grape设计微服务架构需要掌握的可选知识某种为部署微服务而设计的开发框架Java：SpringBoot、Dropwizard常用微服务运维工具服务自动负载均衡ConsulEureka：基于AWS的服务负载均衡NginxHAProxy日志、监控ELK：Elasticsearch/Logstash/KibanaZabbix基于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（容器即服务）结合优点：不需要做大量的运维工作、控制力度强、可移植性好缺点：学习成本较高不同团队看待微服务的不同视角产品设计团队视角更大的灵活性更强的响应力开发团队视角更便于维护更便于增量迭代式开发测试团队视角更容易测试上线回归时间更短运维团队视角更好的可伸缩性、高可用性更容易部署更容易监控微服务系统的团队管理康威定律（ConwaysLaw）任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构来说，都会与 该该组织组织的沟通结构的沟通结构 保持一致。必须有整体的规划和相关规范划分界定的上下文根据界定的上下文划分服务制定并维护服务设计规范、监控规范微服务系统的团队管理团队组织应与划分的领域模型（上下文）匹配产品设计团队开发团队测试团队充分授权让小团队完全拥有某个领域模型及其上服务的所有权所有权涵盖需求、构建、部署、运维等服务的全生命周期微服务的反模式纵欲（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）：创建了一个分布式的单块应用现象：无法独立部署服务，多个相互依赖的、紧耦合的服务必须同时部署将设计单块应用的方法直接应用到设计微服务上面，产生了很多小的单块应用。这些小的单块应用没有拥抱 单一职责原则单一职责原则（singleresponsibilityprinciple，SRP），相互之间依赖严重，导致必须采用复杂的部署过程。解决方法：需要密切关注服务的职责和API设计和协议必须是能够自动化验证并不断强化的人类有喜欢走捷径的天性，但是不要总是“走捷径”微服务的反模式暴怒（Wrath）：发生了糟糕的事情就会引发连锁爆炸现象：因为某个消息队列的拥塞，引发连锁反应，最终导致整个系统无法对外提供服务解决方法开发人员需要进行防御式编程，实现一些容错模式，例如超时时间、重试机制、断路器、舱壁等等。运维人员从思想和职责上需要拥抱DevOps，需要开发相关的工具链来支持快速供给、基础监控、快速应用部署。必须把压力传递给所有的运维和开发人员，应该经常搞灾难恢复演习一切问题都是人的问题！一切问题都是人的问题！微服务的反模式嫉妒（Envy）：分享单个领域模型现象：为了满足大量的报表/分析需求，使用单个大型数据库，不愿意分割数据库解决方法：通过ETL工具实现数据中心，汇集多个服务的数据在数据中心实现报表/分析需求微服务的反模式傲慢（Pride）：难以测试不稳定的微服务系统现象：测试环境中各个服务都处在不稳定的状态，整体行为难以预测不同的测试人员，可能在同时测试有依赖关系的多个服务解决方法：建立两个测试环境：不稳定环境和稳定环境稳定环境中部署的是全部生产环境已部署的稳定版本，不稳定环境部署的某个待测服务连接到稳定环境中的服务隔离变化，确保只有当前待测的服务是变化的微服务的现实主义微服务架构不是银弹，也不是共产主义社会微服务是 设计分布式系统的常识和最佳实践的汇总设计分布式系统的常识和最佳实践的汇总良好的微服务架构不是一蹴而就的需要有一个长期的进化过程需要有强有力的、持续的规划和管理需要不断学习、不断提炼微服务架构依赖于持续集成持续提高自动化测试的比重单元测试、验收测试、回归测试、性能测试经常做重构勿以善小而不为，勿以恶小而为之结束语拥抱微服务架构，设计易于维护的、可伸缩性+高可用性优秀的分布式系统！参考图书资料微服务设计，SamNewman著TheDevOps2.0Toolkit，ViktorFarcic著领域驱动设计：软件核心复杂性应对之道REST实战，JimWebber等著微服务：架构与实践，王磊著SpringBoot揭秘：快速构建微服务体系，王福强著SOA与REST：用REST构建企业级SOA解决方案，ThomasErl等著微服务的“七宗罪”感谢您的聆听！我的联系方式：邮箱：dlee.cngmail.com“REST实战讨论组”QQ群：81207617