微服务架构学习笔记(一):重新认识微服务

果子爸聊技术 2018-08-31 14:05:12 ⋅ 883 阅读

一、什么是微服务

微服务(Microservice)是服务化思路的一种最佳实践方向,遵循SOA的思路,各个企业在服务化治理的道路上走的时间长了,踩的坑多了,整个软件交付链路上各个环节的基础设施逐渐成熟了,微服务自然而然就诞生了。

早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元,而微服务实现和实施思路则更强调功能趋向单一,服务单元小型化和微型化。(如果用“茶壶煮饺子”来打比方的话,原来我们是在茶壶里煮很多饺子,微服务化之后则基本上是在一个茶壶煮一个饺子,而这些饺子就是服务的功能,茶壶则将这些服务功能打包交付的服务单元)。


所以,从思路和理念上来讲,微服务就是要倡导大家尽量将功能进行拆分,将服务粒度做小,使之可以独立承担对外服务的职责,沿着这个思路开发和交付的软件服务实体就叫做“微服务”,而围绕这个思路和理念构建的一系列基础设施和指导思想,称为“微服务体系”。

二、微服务因何而生

随着软件系统的复杂度持续飙升,软件交付的效率要求更高,投入的人力以及各项资源越来越多,基于Monolith的服务化思路就不能满足了(Monolith服务化思路:通常将所有功能的实现都统一到一个开发项目下,但随着功能的膨胀,这些功能一定会分发给不同的开发人员进行开发,造成的后果就是,大家在提交代码的时候频繁冲突,并需要解决这些冲突,单一的开发项目成为了开发期间研发团队的工作瓶颈)。

为了减轻这些苦恼,我们将按照要开发的功能拆分为不同的项目,而负责不同功能的研发人员就可以在自己的代码项目上进行开发,从而解决了大家无法在开发阶段并行开发的苦恼。

总结:一方面微服务可以帮助我们应对飙升的系统复杂度;因一方面微服务可以帮助我们进行更大范围的扩展,从开发阶段项目并行开发的扩展,到交付阶段并行交付的扩展,再到相应的组织结构和组织能力的扩展,都因微服务而受益。

三、微服务带来的好处

1、独立,独立,再独立

可以把每一个微服务都看做一个小的王国,开始从各个层面打造自己的独立能力,从而保障自己的小王国可以持续稳固的运转。

首先,从开发层面来看,每一个微服务基本上都是各自独立的项目(project),而对应各自独立项目的研发团队基本上也是独立对应,这样的结构保证了微服务的并行研发,并且各自快速迭代,不会因为所有研发都投入一个近乎单点的项目,从而造成开发阶段的瓶颈。开发阶段的独立,保证了微服务的研发可以高效运行。简而言之,就是开发的时候各自进行,交付的时候也可以独立交付,从而使得每个微服务从开发到交付整条链路上都是独立进行,大大加快产品的迭代和交付效率。
微服务交付之后需要部署运行,对微服务来说,它们运行期间也是各自独立的(独立运行的好处:第一个就是可扩展性。可以快速的添加服务集群的实力,提升整个微服务集群的服务能力,而在传统的Monolith模式下,为了能够提升服务能力,必须强化和扩展单一节点的服务能力来达成。如果扩展到极限的话就要从软件到硬件整体进行重构了)。

对于Java开发者来说,Web应用都需要以WAR包的形式部署到tomcat、jetty等web容器中运行,即使每个war包提供的都是独立的微服务,但他们都是统一部署在一个web容器中,所以扩展能力受限于web容器作为一个进程的现状,无论如何调整web容器内部实现的线程设置还是会受限于web容器整体的扩展能力,所以现在大家都是一个web容器部署一个war,然后通过复制和扩展多个容器实例来扩展整个应用服务集群。

一个web容器中只部署一个war包的做法带给我们第二个好处,即隔离性。当我们将每个微服务都隔离为独立的运行单元后任何一个或多个微服务的失败都将只影响自己或者少量其他微服务,而不会大面积的波及整个服务运行体系(架构设计上交隔板模式)。

2、多语言生态

微服务既可以使用Java或Go等静态语言完成微服务的开发和交付也可以使用Python或Ruby等动态语言完成微服务的开发和交付,对于团队内部拥有多语言的组织奶说,可以最大化的发挥团队和组织内部各成员的优势(一定要统一微服务的服务接口和协议)。


微服务带来的挑战

服务“微”化之后,最显著的特点就是服务的数量增多了,而数量大的这一特点则决定了我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系,这些都涉及人力和资源成本,往往这些都是受限的。


---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦



全部评论: 0

    我有话说:

    你的老板逼你上服务了吗?

    “ 这些年软件的设计规模越来越庞大,业务需求也越来越复杂,针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。   图片来自 Pexels可以说业务需求是软件架构能力的

    架构实战篇:认识服务架构

    服务是一个新兴的软件架构,就是把一个大型的单个应用程序和服务拆分为数十个的支持服务

    【开源资讯】JWCloud 专业版 v1.0.0 发布,基于 SpringCloud 研发的服务框架

    简介 JavaWeb_Cloud 服务平台是款基于 SpringCloud 框架研发的分布式微服务框架,主要使用技术栈包括: SpringCloud、Vue、ElementUI

    服务架构学习笔记:gRPC Spring Boot Starter 2.2.0 发布,及使用步骤

    gRPC Spring Boot Starter 项目是一个 gRPC 的 Spring Boot 模块。内嵌一个 gRPC Server 对外提供服务,并支持 Spring Cloud 的服务发现

    「转载」服务分布式架构中,如何实现日志链路跟踪?

    背景 开发排查系统问题用得最多的手段就是查看系统日志,在分布式环境中一般使用ELK来统一收集日志,但是在并发大时使用日志定位问题还是比较麻烦,我们来看下面的图     上图一个用户请求一个url,整个链路如图,每个处理层...

    服务架构下的若干常用设计模式

    在我们选择了用服务架构来设计、交付数字化应用后,因服务架构本身所带来的一些共性问题。

    【分享】次单体架构改造成服务架构的拆分实践

    从5个方面设计这次服务的拆分方案,以及经验总结!

    架构实战篇:一个可供中小团队参考的服务架构技术栈

    作者近年一直在一线互联网公司(携程,拍拍贷等)开展服务架构实践,根据我个人的一线实践经验和我平时对Spring Cloud的调研,我认为Spring Cloud技术栈中的有些组件离生产级开发尚有

    码云推荐:一个优秀的分布式spring boot/Spring Cloud API限流框架,特别适合服务架构

    一个优秀的分布式spring boot/Spring Cloud API限流框架,特别适合服务架构.

    服务架构:搭建网站扫码登录的功能设计

    信扫码登录大家都是应用比较多的登录方式了,现在大的购物网站像京东、淘宝等都支持使用APP扫码登录网站了。今天就用APP扫码登录网站的实例来举例说明服务架构的搭建过程。

    SpringBoot+zk+dubbo架构实践(三):部署Dubbo-admin管理平台

    本系列架构实践不做深入探讨,主旨是带领大家能够快速踏入服务架构门槛,能够轻松的搭建套属于自己的服务架构。——写代码我们是认真滴!

    精品推荐:服务架构下静态数据通用缓存机制

    在分布式系统中,特别是最近很火的服务架构下,有没有或者能不能总结出一个业务静态数据的通用缓存处理机制或方案,这篇文章将结合一些实际的研发经验,尝试理清其中存在的关键问题以及探寻通用的解决之道。

    SpringBoot+zk+dubbo架构实践():本地部署zookeeper

    SpringBoot+zk+dubbo架构实践系列实现目标:自己动手搭建服务架构

    分钟认识服务网关zuul及案例实操

    服务架构模式下后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。

    服务调用为啥都选择使用用RPC,http不更简单吗?

    最近在整理服务技术架构体系,抛出一个问题大家讨论下!  

    小型系统如何“服务”开发

    提到“服务”,我相信网上各种“服务”的演变案例都会给人种“因大而分”的前提错觉,这可能会导致许多的“小白”产生没有机会接触“大项目”而对“服务”可望而不可及也。

    信小程序实战篇:如何解决https域名问题 ?

    开发自己的信小程序绕不开https问题,为了能在小程序中调用我们自己的API服务请打开看看吧!!!

    字节跳动 | 服务架构中如何优雅地重试?

    背景 在服务架构中,一个大系统被拆分成多个小服务,小服务之间大量 RPC 调用,经常可能因为网络抖动等原因导致 RPC 调用失败,这时候使用重试机制可以提高请求的最终成功率,减少故障影响,让系统