医学常见的微服务设计入门.ppt

微服务设计入门 设计分布式系统的常识和最佳实践汇总 主讲人：李锟 什么是微服务？ 全称微服务架构：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） 共享内核（Sh