微服务(Microservices)概述

目录

单体应用与架构

微服务·MicroServices

微服务和 SOA

微服务开发框架


单体应用与架构

1、一个归档包(war 包、jar 包...)包含了应用所有功能的应用程序, 通常称之为单体应用。 

2、架构单体应用的架构风格, 称之为单体架构, 这是一种比较传统的架构风格。

3、一个单体应用系统是以一个单个单元的方式来构建的,企业应用系统经常包含三个主要部分:客户端用户界面、数据库和服务端应用系统。客户端用户界面包括HTML页面和运行在用户机器的浏览器中的JavaScript。数据库中包括许多表,这些表被插入一个公共的且通常为关系型的数据库管理系统中。这个服务端的应用系统就是一个单体应用——一个单个可执行的逻辑程序。对于该系统的任何改变,都会涉及构建和部署服务端应用系统的一个新版本。通过负载均衡器运行许多实例,可以将这个单体应用进行横向扩展。

4、单体/块应用系统可以被成功地实现,但是渐渐地,特别是随着越来越多的应用系统正被部署到云端,人们对它们开始表现出不满。软件变更受到了很大的限制,应用系统的一个很小的部分的一处变更,也需要将整个单块应用系统进行重新构建和部署。随着时间的推移,单块应用开始变得经常难以保持一个良好的模块化结构,这使得它变得越来越难以将一个模块的变更的影响控制在该模块内。当对系统进行扩展时,不得不扩展整个应用系统,而不能仅扩展该系统中需要更多资源的那些部分。

单体架构存在的缺点

1)复杂性逐渐变高,项目越大,复杂性越高
2)技术债务逐渐上升,随着项目增大,维护成本也越高

随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。“不坏不修(Not broken,don’t fix)”,这在软件开发中非常常见,在单体应用中这种思想更甚。已使用的系统设计或代码难以修改,因为应用程序的其他模块可能会以意料之外的方式使用它。

3)部署速度逐渐变慢

随着代码的增多,构建和部署的时间也会增加。而在单体应用中,每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高,这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错概率比较高。

4)阻碍技术创新,牵一发而动全身。

单体应用往往使用统一的技术平台或方案解决所有问题,团队的每个成员都必须使用相同的开发语言和框架,想要引入新的框架或技术平台会非常困难。例如,一个使用Struts 2构建的、100万行代码的单体应用,如果想要换用Spring MVC,切换成本无疑是非常高的。

5)无法按需伸缩

单体应用只能作为一个整体进行扩展,无法结合业务模块的特点进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU;有的模块则是IO密集型的,需要更大的内存。由于这些模块部署在一起,我们不得不在硬件的选择上做出妥协。

架构的演进

1)单体架构
2)SOA(Service-Oriented Architecture 面向服务的架构),可以参考:https://www.jdon.com/soa.html
3)微服务

微服务·MicroServices

1、“微服务(Microservices)架构”这个术语最近几年横空出世,来描述这样一种特定的软件设计方法,即以若干组可独立部署的服务的方式进行软件应用系统的设计。尽管这种架构风格尚无精确的定义,但其在下述方面还是存在一定的共性,即围绕业务功能的组织、自动化部署、端点智能、和在编程语言和数据方面进行去中心化的控制。

2、微服务(Microservices)架构风格是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务仅做最低限度的集中管理(去中心化)。

3、因为人们逐渐对单体应用不满,从而导致了微服务架构风格的诞生:以构建一组小型服务的方式来构建应用系统。除了这些服务能被独立地部署和扩展,每一个服务还能提供一个稳固的模块边界,甚至能允许使用不同的编程语言来编写不同的服务。这些服务也能被不同的团队来管理。

微服务架构九大特性

特性一:“组件化”与“多服务”
特性二:围绕“业务功能”组织团队
特性三:“做产品”而不是“做项目”
特性四:“智能端点”与“傻瓜管道”
特性五:“去中心化”地治理技术
特性六:“去中心化”地管理数据
特性七:“基础设施”自动化
特性八:“容错”设计
特性九:“演进式”设计

更多详细内容可以参考:

1)“微服务”原文链接:http://martinfowler.com/articles/microservices.html
2)“微服务”译文链接:http://mp.weixin.qq.com/s?__biz=MjM5MjEwNTEzOQ==&mid=401500724&idx=1&sn=4e42fa2ffcd5732ae044fe6a387a1cc3#rd

微服务优点

1)易于开发和维护

一个微服务只关注一个特定的业务功能,所以它的业务清晰、代码量较少。开发和维护单个微服务相对是比较简单的。而整个应用是由若干个微服务构建而成的,所以整个应用也会维持在可控状态

2)启动较快

单个微服务代码量较少,所以启动会比较快。

3)局部修改容易部署

单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。

4)技术栈不受限

在微服务中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库MySQL;某些微服务有图形计算的需求,可以使用Neo4J;甚至可以根据需要,部分微服务使用Java开发,部分微服务使用NodeJS进行开发。

5)按需伸缩

可以根据需求,实现细粒度的扩展。例如:系统中的某个微服务遇到了瓶颈,可以结合这个微服务的业务特点,增加内存、升级CPU或者是增加节点。

微服务带来的挑战

1)运维要求较高

更多的服务意味着更多的运维投入。在单体架构中,只需要保证一个应用的正常运行;而在微服务中,需要保证几十甚至几百个服务的正常运行与协作,这给项目的运维带来了很大的挑战。

2)分布式的复杂性

使用微服务构建的是分布式系统,对于一个分布式系统,系统容错、网络延迟、分布式事务等都带来了很大的挑战。

3)接口调整成本高

微服务之间通过接口进行通信。如果修改某一个微服务的API,可能所有使用了该接口的微服务都需要做调整。

4)重复劳动

很多服务可能都会使用到相同的功能,而这个功能并没有达到分解为一个微服务的程度,这个时候,可能各个服务都会开发这一功能,从而导致代码重复。 

微服务设计原则

1)单一职责原则
2)服务自治原则

服务自治是指每个微服务应该具备独立的业务能力、依赖与运行环境。

3)轻量级通信原则
4)接口明确原则

每个服务的对外接口应该明确定义,并尽量保持不变。

微服务和 SOA

1、当谈到微服务时,一个常见的问题就会出现:是否微服务仅仅是十多年前所看到的“面向服务的架构”(Service Oriented Architecture, SOA)?这样问是有道理的,因为微服务风格非常类似于一些支持SOA的人所赞成的观点。然而,问题在于SOA这个词儿意味着太多不同的东西。而且大多数时候,所遇到的某些被称作"SOA"的事物,明显不同于微服务所描述的风格。这通常由于它们专注于ESB,来集成各个单块应用。

2、特别地,已经看到如此之多的面向服务的拙劣实现——从将系统复杂性隐藏于ESB中的趋势,到花费数百万进行多年却没有交付任何价值的失败项目,到顽固抑制变化发生的中心化技术治理模型——以至于有时觉得其所造成的种种问题真的不堪回首。

3、当然,在微服务社区投入使用的许多技术,源自各个开发人员将各种服务集成到各个大型组织的经验。“容错读取”(Tolerant Reader, http://martinfowler.com/bliki/TolerantReader.html)模式就是这样一个例子。对于Web的广泛使用,使得人们不再使用一些中心化的标准,而使用一些简单的协议。坦率地说,这些中心化的标准,其复杂性已经达到令人吃惊的程度(http://wiki.apache.org/ws/WebServiceSpecifications)。(任何时候,如果需要一个本体(ontology)来管理其他各个本体,那么麻烦就大了。)

4、这种常见的SOA的表现,已使得一些微服务的倡导者完全拒绝将自己贴上SOA的标签。尽管其他人会将微服务看作是SOA的一种形式,也许微服务就是以正确的形式来实现面向服务的SOA。不管是哪种情况,SOA意味着如此之多的不同事物,这表明用一个更加干净利落的术语来命名这种架构风格是很有价值的。

微服务开发框架

1、微服务到现在已经经过了很长时间的沉淀,现在市面上开源的微服务框架也有很多,无论是国外的,还是国产的

2、Spring Cloud:https://spring.io/projects/spring-cloud

3、Dubbo:http://dubbo.apache.org/zh-cn/       这原本是阿里巴巴内部使用,后面开源到了 Apache 。

4、Dropwizard:https://www.dropwizard.io/1.3.9/docs/  

参考文章:《Dropwizard 与 Spring Boot 比较》

参考文章:《比较spring cloud和dubbo,各自的优缺点是什么》

5、显然对于一直以 Spring -> Spring Boot -> Spring Cloud 这种学习使用路线走的,开发微服务肯定首选 Spring Cloud。

更多微服务详细内容可以参考:

1)“微服务”原文链接:http://martinfowler.com/articles/microservices.html
2)“微服务”译文链接:http://mp.weixin.qq.com/s?__biz=MjM5MjEwNTEzOQ==&mid=401500724&idx=1&sn=4e42fa2ffcd5732ae044fe6a387a1cc3#rd

猜你喜欢

转载自blog.csdn.net/wangmx1993328/article/details/87900587