可信网站认证费用,建设一个网站可以采用那几方案,圣诞树html网页代码,工商网目录 前言阅读对象阅读导航前置知识笔记正文一、系统架构的演变1.1 单体架构1.2 单体水平架构1.3 垂直架构1.4 SOA架构1.5 微服务架构 二、如何实现微服务架构2.1 微服务架构下的技术挑战2.2 微服务技术栈选型2.3 什么是Spring Cloud全家桶2.4 Spring Cloud Alibaba版本选择 学… 目录 前言阅读对象阅读导航前置知识笔记正文一、系统架构的演变1.1 单体架构1.2 单体水平架构1.3 垂直架构1.4 SOA架构1.5 微服务架构 二、如何实现微服务架构2.1 微服务架构下的技术挑战2.2 微服务技术栈选型2.3 什么是Spring Cloud全家桶2.4 Spring Cloud Alibaba版本选择 学习总结 前言
事实上我个人对单体到微服务架构的演进尽管能够理解但总是觉得差点意思所以这边在学习之余顺便写个笔记总结一下加深一下印象吧。
阅读对象
阅读导航
系列上一篇文章《【微服务专题】SpringBoot自动配置简单源码解析》
前置知识
笔记正文
一、系统架构的演变
别看微服务架构牛逼哄哄的样子但真要从市场上来说没有最好的架构只有最合适的架构。存在即合理。 通常来说我们认为架构发展历史经历了这样一个过程单体架构 - 垂直架构 - SOA面向服务架构 - 微服务架构。 接下来我们从每个架构的特点以及遇到的问题、如何解决等角度来给大家介绍一下每个架构。
1.1 单体架构
基本介绍 单体架构嘛我们普通Java程序员接触过最多的一种架构模式了。简单来说就是一个SpringBoot应用通常来说所有的业务功能都部署在一块这样可以减少开发、部署和维护的成本。
特点 所有功能模块都在一个应用里面一旦应用宕机、或者正常运维关闭启动期间所有服务都不可用
架构图示 优点
项目架构简单结构也简单在项目不大的时候开发运维成本较低 项目小的时候是这样项目大的时候你就会戴上痛苦面具了 缺点 下面说的缺点也正是这个架构在演进当中面临的挑战
全部功能集成在一个工程中对于大型项目来讲不易开发和维护 我们公司现在的架构局部来说就是这样ALL-IN-ONE每次打包编译启动都要7、8分钟好一点的机器也是5、6分钟。这基本注定了你不能在高峰期重启服务一旦重启就是生产事故 项目模块之间紧密耦合单点容错率低无法针对不同模块进行针对性优化和水平扩展 这一点我个人认为可能是最重要的一点。还是拿我公司现在的项目来说某些模块其实负载特别大但由于项目架构的问题没办法精准分配流量、硬件资源等多少是有点浪费的 不过在单体架构的演进过程中首先遇到的问题并非模块化问题而是随着用户量越来越大网站的访问量不断增大导致后端服务器的负载越来越高 还是拿我们公司举例我们从17年刚开始踏足团餐领域的时候没多少个客户所以一台服务器就解决了。但是随着业务的扩张我们全国已经有8000的客户分布在全国各地无论是从硬件资源还是运维部署来看一台服务器肯定不行的。这时候我们公司就开始了水平扩张的演进。
1.2 单体水平架构
严格来说还是属于单体架构只不过做了水平拓展而已架构图如下 当然随着业务深入我们公司也开始了一些其他尝试。以前所有功能都写在一个工程目录下迭代了6、7年之后我的大佬们应该也无法忍受了你懂的。五花八门的代码别具一格的代码风格使得维护、升级改造成本极高所以渐渐的一些比较独特的业务也被抽离出来单独部署一台服务器这种架构方式我们可以称之为垂直架构。
1.3 垂直架构
基本介绍 所谓水平拓展多个一摸一样内容的应用 所谓垂直拓展简单来说专服专用。从业务的垂直领域进行拆分减少业务的耦合度以及降低单个war包带来的伸缩性困难问题
特点 专服专用
优点
系统拆分实现了流量分担可以针对不同模块进行优化方便水平扩展负载均衡容错率提高系统间相互独立互不影响新的业务迭代时更加高效
缺点
服务之间相互调用如果某个服务的端口或者IP地址发生改变。调用的系统得手动变化 这个我深有体会。由于只是简单的垂直架构也没有接入熔断器之类的东西所以其中一个环节出错对调用方的影响是巨大的特别是在日志不全报错提示又不友好的前提下排查问题想当麻烦 服务之间调用方式不统一基于httpclient,webservice接口协议不统一搭建集群之后实现负载均衡比较复杂。比如内网负载在迁移得时候会影响调用方的路由导致线上故障服务监控不到位
但其实在我们公司的垂直架构开发中我个人还是遇到了一些很让人无奈的问题。诸如
系统之间很多重复的业务但由于彼此之间是独立的逻辑无法完全共享不同系统之间会产生各自的信息有时候希望获得对方的信息但这种信息获取又不是那么便捷很多时候需要额外写接口传递。所以就造成这样的现象明明都是同属于同一个公司的东西但是彼此之间共享不便捷软件架构领域称之为信息孤岛
基于上述这些缺点及问题于是有人提出了SOA架构。
1.4 SOA架构
SOAService-Oriented Architecture也就是面向服务的架构。在SOA中会采用ESB企业服务总线来作为系统和服务之间的通信桥梁ESB本身还提供服务地址的管理、不同系统之间的协议转化和数据格式转化等。调用端不需要关心目标服务的位置从而使得服务之间的交互是动态的这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。 总的来说SOA主要解决的问题是
共享业务的重用信息孤岛
特点
服务地址管理协议转换数据转换
架构图
优点
使用治理中心ESB解决了服务间调用关系的自动调节
缺点
服务间会有依赖关系一旦某个环节出错会影响较大( 服务雪崩 ) 引入了更多中间件意味着系统复杂度会上升。比如引入redis、mq等这两个玩意在没有做高可用的情况下任何一个崩溃了都会导致服务雪崩。 服务关系复杂运维、测试部署困难
其实上面说的缺点咱也不知道这算不算缺点百度是这么说的。但是不可否认的是随着更多系统、中间件的引入不可避免地增加了运维成本。
1.5 微服务架构
严格来说微服务架构算是SOA架构的进一步优化它更加强调服务的【彻底拆分】。面向服务SOA和微服务本质上都是服务化思想的一种体现。从架构图来看微服务其实就是一个SOA下面包含多个SOA然后最小的SOA就是一个微服务。 伴随着服务粒度的细化会导致原本10个服务可能拆分成了100个微服务一旦服务规模扩大就意味着服务的构建、发布、运维的复杂度也会成倍增加所以实施微服务的前提是软件交付链路及基础设施的成熟化。 由于SOA和微服务两者的关注点不一样造成了这两者有非常大的区别
SOA关注的是服务的重用性及解决信息孤岛问题微服务关注的是解耦虽然解耦和可重用性从特定的角度来看是一样的但本质上是有区别的解耦是降低业务之间的耦合度而重用性关注的是服务的复用微服务会更多地关注在DevOps的持续交付上因为服务粒度细化之后使得开发运维变得更加重要因此微服务与容器化技术的结合更加紧密
微服务架构就是将每个具体的业务服务构成可独立运行的微服务每个微服务只关注某个特定的功能服务之间采用轻量级通信机制REST API进行通信。
优点
复杂度可控通过对共享业务服务更细粒度的拆分一个服务只需要关注一个特定的业务领域并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低开发、维护会更加简单技术选型更灵活每个微服务都由不同的团队来维护所以可以结合业务特性自由选择技术栈可扩展性更强可以根据每个微服务的性能要求和业务特点来对服务进行灵活扩展比如通过增加单个服务的集群规模提升部署了该服务的节点的硬件配置独立部署由于每个微服务都是一个独立运行的进程所以可以实现独立部署。当某个微服务发生变更时不需要重新编译部署整个应用并且单个微服务的代码量比较小使得发布更加高效容错性在微服务架构中如果某一个服务发生故障我们可以使故障隔离在单个服务中。其他服务可以通过重试、降级等机制来实现应用层面的容错
缺点
故障排查一次请求可能会经历多个不同的微服务的多次交互交互的链路可能会比较长每个微服务会产生自己的日志在这种情况下如果出现一个故障开发人员定位问题的根源会比较困难服务监控在一个单体架构中很容易实现服务的监控因为所有的功能都在一个服务中。在微服务架构中服务监控开销会非常大可以想象一下在几百个微服务组成的架构中我们不仅要对整个链路进行监控还需要对每一个微服务都实现一套类似单体架构的监控分布式架构的复杂性微服务本身构建的是一个分布式系统分布式系统涉及服务之间的远程通信而网络通信中网络的延迟和网络故障是无法避免的从而增加了应用程序的复杂度服务依赖微服务数量增加之后各个服务之间会存在更多的依赖关系使得系统整体更为复杂。假设你在完成一个案例需要修改服务A、B、C而A依赖BB依赖C。在单体式应用中你只需要改变相关模块整合变化再部署就好了。对比之下微服务架构模式就需要考虑相关改变对不同服务的影响。比如你需要更新服务C然后是B最后才是A幸运的是许多改变一般只影响一个服务需要协调多服务的改变很少运维成本在微服务中需要保证几百个微服务的正常运行对于运维的挑战是巨大的。比如单个服务流量激增时如何快速扩容、服务拆分之后导致故障点增多如何处理、如何快速部署和统一管理众多的服务等
二、如何实现微服务架构
2.1 微服务架构下的技术挑战
微服务架构主要的目的是实现业务服务的解耦。随着公司业务的高速发展微服务组件会越来越多导致服务与服务之间的调用关系越来越复杂。同时服务与服务之间的远程通信也会因为网络通信问题的存在变得更加复杂比如需要考虑重试、容错、降级等情况。那么这个时候就需要进行服务治理将服务之间的依赖转化为服务对服务中心的依赖。除此之外还需要考虑
服务的注册与发现分布式配置中心服务路由负载均衡熔断限流分布式链路监控
这些都需要对应的技术来实现我们是自己研发还是选择市场上比较成熟的技术拿来就用呢如果市场上有多种相同的解决方案应该如何做好技术选型
2.2 微服务技术栈选型
业内比较主流的微服务解决方案进行分析主要包括
Spring Cloud NetflixSpring Cloud Alibaba
毫无疑问我们选择Spring Cloud Alibaba
2.3 什么是Spring Cloud全家桶
Spring Cloud提供了一些可以让开发者快速构建微服务应用的工具比如配置管理、服务发现、熔断、智能路由等这些服务可以在任何分布式环境下很好地工作。Spring Cloud主要致力于解决如下问题
Distributed configuration分布式配置Service registration and discovery服务注册与发现Routing服务路由Service-to-service calls服务调用Load balancing负载均衡Circuit Breakers断路器Distributed messaging分布式消息
需要注意的是Spring Cloud并不是Spring团队全新研发的框架它只是把一些比较优秀的解决微服务架构中常见问题的开源框架基于Spring Cloud规范进行了整合通过Spring Boot这个框架进行再次封装后屏蔽掉了复杂的配置给开发者提供良好的开箱即用的微服务开发体验。不难看出SpringCloud其实就是一套规范而Spring Cloud Netflix、Spring Cloud Alibaba才是Spring Cloud规范的实现。 Alibaba的开源组件在服务治理上和处理高并发的能力上有天然的优势毕竟这些组件都经历过数次双11的考验也在各大互联网公司大规模应用过。所以相比Spring Cloud Netflix来说SpringCloud Alibaba在服务治理这块的能力更适合于国内的技术场景同时Spring Cloud Alibaba在功能上不仅完全覆盖了Spring Cloud Netflix原生特性而且还提供了更加稳定和成熟的实现
2.4 Spring Cloud Alibaba版本选择 SpringCloud版本说明 SpringClound与SpringBoot版本对应关系 组件版本关系 比如我现有项目SpringBoot版本是2.6.4故选择2021.0.1.0版本的SpringCloud。所以选择的组件本本分别如下
学习总结
学习了微服务架构的演进
