开篇以前先声明我对微服务的几点态度:前端
架构模式有不少,微服务不是惟一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新,也能看出作此种技术选型的工程师基础架构素质的不足。数据库
“你必须长的足够高才能使用微服务”。微服务基础设施,尤为是容器技术、自动化部署、自动化测试这些不完备,微服务形同虚设,不会带来什么质的提高。编程
微服务架构的关键不在于具体的实现,而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。设计模式
Spring Boot是Spring全家桶的上层封装,并非什么崭新的技术,也不是什么值得以为成为本身杀手锏的技术。浏览器
Spring Cloud中Spring Cloud Netflix的组件是通过生产环境验证的,其余的则建议慎重选择。安全
微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务(Micro-Web-Service),根本思想相似于Unix的管道设计理念。2014年,由Martin Fowler 与 James Lewis共同提出了微服务的概念,定义了微服务架构风格是一种经过一套小型服务来开发单个应用的方法,每一个服务运行在本身的进程中,并经过轻量级的机制进行通信(HTTP API)。关键的三点是small、automated以及lightweight。网络
对比SOA,微服务能够看作是SOA的子集,是轻量级的SOA,粒度更细的服务,独立进程、数据分离,更注重敏捷、持续交付、DevOps以及去中心化实践。其共同的架构原理:架构
特色:app
优势:负载均衡
缺点:
是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的,可是随之而来的就是引入了微服务自己的复杂度。须要解决包括自动化部署、监控、容错处理、最终一致性等其余分布式系统面临的问题。即便已经有一些广泛使用的解决方案,可是仍然是有不小的成本的。
生产力和复杂度的关系如图所示,可见系统越复杂,微服务带来的收益越大。此外,不管是单体应用仍是微服务,团队的技能都须要可以把控住。
马丁.福勒的一个观点是:除非管理单体应用的成本已经太复杂了(太大致使很难修改和部署),不然都不要考虑微服务。大部分应用都应该选择单体架构,作好单体应用的模块化而不是拆分红服务。
所以,系统一开始采用单体架构,作好模块化,以后随着系统变得愈来愈复杂、模块/服务间的边界愈来愈清晰,再重构为微服务架构是一个合理的架构演化路径。
四个能够考虑上微服务的状况:
此外,根据康威定律和逆康威定律(技术架构倒逼组织架构改进),组织架构也是一个很关键的因素。对应于微服务架构,组织架构须要遵循如下原则:
微服务的推行须要依赖于不少底层基础设施,包括提供微服务的编译、集成、打包、部署、配置等工做,采用PaaS平台解决微服务从开发到运行的全生命周期管理,同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。
最基本的基础设施
提高外部服务对接效率和内部开发效率
提高测试和运维效率
进一步提高运维效率
在微服务数量不多的状况下,以上基础设施的优先级自上而降低低。不然,仅仅依赖人工操做,则投入产出比会很低。
还须要提到的是Docker容器技术。虽然这个对于微服务并非必须的,可是容器技术轻量级、灵活、与应用依存、屏蔽环境差别的特性对于持续交付的实现是相当重要的,即便对于传统的单体应用也可以给其带来交付效率的大幅提高。
在引入微服务以后,传统的单体应用变为了一个一个服务,以前一个应用直接提供接口给客户端访问的架构再也不适用。微服务架构下,针对不一样设备的接口作为BFF层(Backend For Frontend),也叫作用户体验适配层,负责聚合、编排微服务的数据转换成前端须要的数据。服务之间的调用则在容许的状况下(容许延迟)尽量使用异步消息传递方式,如此造成面向用户体验的微服务架构设计模式。以下图所示:
Client -> API Gateway -> BFF(Backend For Frontend) -> Downstream Microservices
微服务架构最核心的环节,主要是对服务的横向拆分。服务拆分就是讲一个完整的业务系统解耦为服务,服务须要职责单一,之间没有耦合关系,可以独立开发和维护。
服务拆分不是一蹴而就的,须要在开发过程当中不断地理清边界。在彻底理清服务以前,尽可能推迟对服务的拆分,尤为是对数据库的拆分。
其中,对于没法修改的遗留系统,采用绞杀者模式:在遗留系统外面增长新的功能作成微服务方式,而不是直接修改原有系统,逐步的实现对老系统替换。
上面讲述了微服务架构的众多基础设施,若是每个基础设施都须要本身开发的话是很是巨大的开发工做。目前市面上已经有很多开源的微服务框架能够选择。
Spring Boot是用来简化新Spring应用的初始搭建以及开发过程的。其虽然不是微服务框架,但其设计的初衷本质就是微应用的底层框架,所以很是适合用于微服务基础设施的开发以及微服务的应用开发。尤为对于Spring技术栈的团队来讲,基于Spring Boot开发微服务框架和应用是天然而然的一个选择。
Dubbo阿里开源的服务治理框架。其出如今微服务理念兴起以前,能够看作是SOA框架的集大成之做。但其仅仅包含了微服务基础设施的部分功能,诸如熔断、服务跟踪、网关等都没有实现。
Motan则是微博开源的相似Dubbo的RPC框架,与Dubbo相比更轻量级。
Spring Cloud是基于Spring Boot实现的微服务框架,也能够看作一套微服务实现规范。基本涵盖了微服务基础设施的方方面面,包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于Spring生态,社区支持很是好。但其不少组件都没有通过生产环境验证,须要慎重选择。
Spring Cloud Netflix是Spring Cloud的一个子项目,是Spring对Netflix OSS的集成实现。基于Netflix的大规模使用,其中的已经被普遍使用的组件包括:
此外,另外一个子项目Spring Cloud Alibaba则是Alibaba开源的基于Spring Boot的微服务框架,主要是对阿里云服务的支持。
上述的微服务框架都是侵入式的,服务化的过程都须要进行代码改造。Service Mesh则是下一代微服务架构,最明显的特征就是无入侵。采用sidecar模式来解决系统架构微服务化后的服务间通讯和治理问题。以下如所示:
目前主流的开源实现包括:
限于Service Mesh带来的性能延迟的开销以及sidecar对分布复杂性的增长,其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。
Linkerd和Envoy:以 sidecar 为核心,关注如何作好proxy,并完成一些通用控制平面的功能。缺少对这些sidecar的管理和控制。
Istio和Conduit:目前最为流行的Service Mesh实现方案,集中在更增强大的控制平面(sidecar被称为数据平面)功能。前者由Google和IBM合做,并使用了Envoy做为sidecar部分的实现;后者则是Linkerd做者的做品。相比起来,Istio有巨头背景,功能强大,但可用性和易用性一直不高,Conduit则相对简单、功能聚焦。
蚂蚁金服开源的构建金融级分布式架构的一套中间件。包括微服务开发框架、RPC框架、服务注册中心、全链路追踪、服务监控、Service Mesh等一整套分布式应用开发工具。
特别值得一提的是SOFAMesh。其实对下一代微服务架构Service Mesh的大规模落地方案实践,基于 Istio改进和扩展而来,应该是国内最为成熟的开源Service Mesh方案。
此外,须要提到Kubernetes(K8s),其自己提供了部分的微服务特性支持(经过域名作服务发现),对代码无侵入。但服务调用、熔断这些都须要本身实现。
综上,目前公司技术团队技术栈是Spring,而且已有服务的实现都是基于Dubbo,所以选择Spring Cloud Netflix作为基础的微服务框架,对其中不成熟或者缺少的组件,选择业界更为成熟的组件替代便可。
来源:https://www.talkwithtrend.com...