广州网站建设(信科分公司),大学加强网站建设与管理的通知,计算机编程网课,网站原型图大小一、传统模式的技术改革 在很多年以前#xff0c;其实没有严格意义上的前后端工程师之分#xff0c;每个后端就是前端#xff0c;同理#xff0c;前端也可以是后端#xff0c;即Ajax、jQuery技术未盛行前的年代。
起初#xff0c;大部分前端界面很简单#xff0c;显示的…一、传统模式的技术改革 在很多年以前其实没有严格意义上的前后端工程师之分每个后端就是前端同理前端也可以是后端即Ajax、jQuery技术未盛行前的年代。
起初大部分前端界面很简单显示的内容几乎以纯静态的文本和图片为核心无法动态渲染后台返回的数据到页面例如
!DOCTYPE html
html langen
headmeta charsetUTF-8title静态页面/title
/head
bodyh1我是竹子爱熊猫~/h1
/body
/html用户能看到的网页内容只能靠硬编码形式写入到代码里这就类似于“一张图片”被制作出来后就无法进行变更想要展示不同的内容只能重新“制作”。
因此当时为了使得Web页面更加灵活生动以PHP、JSP、ASP等为代表的动态页面渲染技术相继诞生所谓的动态页面渲染则是指“页面”并不是固定写死的而是提前定义好模板运行时动态获取数据并渲染生成页面源码例如 !DOCTYPE html
html langen
headmeta charsetUTF-8title动态渲染页面/title
/head
bodyh1${welcomeMessage}/h1
/body
/html此时注意看在上述示例中通过${welcomeMessage}占位符表示这里需要动态获取并渲染一句欢迎语。运行时当出现该页面的请求时会先执行对应操作动态获取欢迎语如查库接着再替换掉前面的占位符从而动态生成网页源码返回给浏览器展示。
这样想要改变欢迎语时就无需重新编写HTML代码只需改变“数据源”的欢迎语即可如改库。凭借着动态页面技术就可以将最新的欢迎语显示出来使得页面更加灵活。
OK从上述背景中不难得知一点早些年的页面源码都依靠“后端”来动态生成比如Java中的JSP技术。正因如此前后端就没有界限分割业务逻辑、页面展示都写在一个应用里面这就是所谓的单体架构 1.1最原始的单机架构 正如上图所示这是最初的部署模式前后端代码、静态资源都往同一个包里怼应用程序、数据库都部署在一台服务器上优势很明显因为都是本机环境内部数据交换非常快同时运维也简单只需要关注这一台服务器即可部署成本非常低。
显然这种方式虽然成本低数据交换快但并不能支撑太大的访问量当流量增大时系统很可能因为CPU、内存、带宽、磁盘等各因素出现性能问题而一旦遇到瓶颈为了保证系统正常运行集“前端、后端、运维、测试、售后……”诸多岗位于一身的小竹只能依靠“升配服务器”来解决。 1.1.1、数据库隔离部署
一味的堆硬件配置并非长久之计尤其站在老板角度出发单机器的配置越高成本会呈几何倍增长此时小竹进行了第一次软件架构层面的优化系统应用与数据库分开部署。 之前一股脑将所有程序部署在一起的做法会导致业务系统和数据库这两个不同的程序相互竞争系统资源在流量较大的情况下由于系统资源不够会导致大量请求处于阻塞中经过拆分后资源相互隔离在极大程度上提升了系统整体的性能。同时就算部署业务程序的机器损坏也不会丢失系统数据在一定程度上也提升了系统的抗风险性。 1.1.2、动静分离 随着业务不断增长小竹没开心几天原先的系统架构出现了新瓶颈因为数据库独立部署而WEB应用服务器即需要处理业务逻辑又需要负责动态生成网页同时还需要处理静态资源请求日渐一日系统不堪重负在某一天下午终于倒下了……
凡事只要有第一次就会有N多次迫不得已的情况下小竹为了保证系统能正常访问只能通过不断重启来解决问题。但这种方法治标不治本总不能一天到晚蹲在服务器旁边重启吧寻找并解决诱发程序频繁宕机的源头才能真正一劳永逸于是小竹踏上了排查之路。
经过一顿操作此时观测到了问题因为部署时所有的静态资源css、js、图片、模板……包括运行期间用户上传的文件统统都放在了WEB容器内托管这意味着所有静态资源请求都需要WEB容器来进行处理。
经过三秒钟的观测后小竹发生这类型的请求占据了60%以上导致频繁宕机的原因就在这里为了解决该问题新的优化方案是动静分离。 经过动静分离的拆分优化后所有静态资源的请求都会去到文件服务器而与业务逻辑相关的请求则会来到WEB服务器通过这种动静分流方案至少能减少WEB服务器60~70%请求小竹终于可以睡上几天安稳觉了 1.1.3、动态页面模板化
前面提到过为了使得网页能动态加载数据PHP、JSP、ASP等技术曾风靡一时以Java的JSP技术来说尽管实现了动态页面的效果可页面内的数据都需要依靠Java来动态填充而渲染页面数据这个工作放在后端来做极为耗费时间与资源。
可当时又没有太好的办法解决直到Ajax、jQuery技术横空出世前端可以通过Ajax请求在不刷新、不跳转新页面的情况下就可以和服务器通信实现异步获取新的数据这也意味着动态页面不再需要依靠后端来生成前端可以异步请求服务器数据来实现页面的数据渲染
放在当时Ajax技术绝对是WEB领域革命性的突破也是在这时IT行业逐渐出现明确的前后端岗位之分前端可以不懂后端技术后端同理两者相互协助从而完成整个系统的开发。在这期间为了避免“后端服务渲染动态页面”带来的开销例如Thymeleaf、FreeMarker、Velocity等各种模板引擎技术蜂拥而至。 看过Tomcat源码的小伙伴应该清楚JSP本质上是一个个的Servlet必须依赖WEB容器才能使用毕竟要靠Java来生成动态页面。而类似于FreeMarker这种模板引擎技术可以脱离Servlet容器运行不再占用JVM内存很大程度上节省了Java生成动态页面所带来的开销。 1.2前后端分离架构 随着时代的进步模板引擎技术仅是昙花一现很快就被全新的模式完全替代那就是流行至今的前后端分离架构
虽然FreeMarker这类模板引擎技术可以不再依赖Servlet容器运行但或多或少会依赖于Java实现渲染而到了该阶段前后端的开始正式“分家”前端涌现了一批又一批的船新技术如 Angular、React、 Vue等页面可以完全不依赖Java、PHP这类环境完成动态渲染Web正式进入2.0时代 到此时前端已经可以完全脱离WEB容器运行这意味着部署时不再需要将视图相关的代码和业务逻辑相关的代码一起打包而是前后端分开部署HTML、CSS、JavaScript等代码作成前端工程单独部署处理业务逻辑的Java代码打包成后端服务单独部署走出了真正意义上的“前后端分离架构”。 因为前端服务已经独立部署后端服务器不再会出现“由于生成动态页面导致资源被耗尽”这类性能瓶颈此时小竹可以高枕无忧了吗我们接着往下看。 1.3集群部署模式 随着日益剧增的访问量就算已经将系统拆分成了前后端分离架构但这也远远不够当用户体量达到一定量级后会造成大量的并发请求而此时的后端服务仅有一个节点并发压力较大时单节点扛不住外部流量轻则响应缓慢重则掉线宕机
当并发数达到单机器的负载极限此刻该怎么办难道又得走上升配的老路吗答案是No曾经在《MySQL专栏-分库分表篇》中讲过一个故事当一匹马拉不动马车时不要想着去找一匹更强壮的马代替它而是可以选择再加一匹、两匹……来一起拉车
同理当一台服务器扛不住并发请求时我们可以选择使用多台服务器来部署系统多个节点均摊处理外部请求从而保证系统的正常运行而这种思想则被称为集群。考虑使用集群来承载更大的流量时首先得解决一个问题原本只有一个节点现在拓展成了多个节点那出现一个请求时究竟该落入到那台机器又该如何分发请求
为了解决上面提到的问题此时得引入两个新的概念请求分发器与负载均衡而目前80%使用集群模式部署的系统大多采用Nginx来实现该效果。当然具体如何做呢没接触过的小伙伴可参考之前的《Nginx篇》。 由于Nginx强大的路由匹配模式如果系统内的静态文件不需要考虑访问权限控制那也可以借助Nginx来实现动静分离。当然Nginx更为重要的是反向代理和负载均衡能力当系统访问量再次出现增长时可以线性拓展出N个节点对外提供更高的吞吐量。
集群化部署的另一个好处在于高可用之前的单机挂掉后整个系统会陷入瘫痪而此时无需担心该问题就算挂掉部分节点还有另一部分节点正常工作系统不会陷入全面瘫痪。终于精神高度紧绷的小竹松了一口气心里想着再也不用担心扛不住请求了大不了再加机器 二、过渡阶段的技术发展 经过上阶段的集群化部署后小竹本以为万事大吉以后再也不用担心系统抗压性跟不上业务增长了可偏偏理想很丰满现实很骨感。确实单从后端层面来说可以横向拓展服务节点来获取更高的吞吐量但小竹忽略了另一个致命环节数据库 2.1、引入缓存中间件解决读并发 并发请求数越来越大之前看似游刃有余的数据库逐渐变的跟不上性能要求而一套系统中技术组件之间都有着千丝万缕的关系一个组件崩溃就容易带来一系列雪崩结果。以数据库为例数据库由于并发影响读取数据越来越慢所以阻塞在后端服务中等待数据返回的请求越来越多入站流量远大于出站流量长此以往后端服务线程数超负荷系统再次出现响应缓慢、无返回等严重事故。
好既然从数据库读取数据较慢有没有好的办法优化呢当然有对于某些热点数据例如电商中的商品SPU主信息变动概率小但访问次数又多。这种情况下能否把这些短期内不会变更的数据直接存放在一处能快速读取的位置呢当然可以缓存的概念由此而来。
对于计算机来说从哪里获取数据最快本机内存而Java程序而言从哪里获取数据最快JVM内存因此Ehcache、Caffeine这类进程级缓存框架应运而生。对于热点数据首次从数据库读取后直接放入缓存中对于后续读取相同数据的请求从缓存中拿出直接返回即可。 通过进程级缓存技术在极大程度上减轻了数据库的读取压力但这种缓存框架通常会与Java程序共享JVM堆空间当缓存数据过多时会造成GC变得更加频繁熟悉JVM-GC机制的伙伴应该清楚GC会造成停顿尤其是次数一多给用户感受就是系统时不时就要卡一下。
虽然这些缓存框架提供了参数允许直接使用本地内存作为缓存区域但在集群环境下依旧存在“数据冗余”问题比如A商品信息在节点1的缓存中上已存在可第二个查看A商品的请求被分发到了节点2此时又会造成节点2缓存一次结合具体的业务场景这时有N个后端节点就会多出N倍的内存占用。
如何将缓存信息公共化MemCache、Redis等分布式缓存中间件的出现完美解决了这个问题。 数据库查询慢首先是因为结构化存储需要遍历表或索引才能定位数据其次是基于磁盘读取本身性能就不咋滴所以在这些缓存中间件里基于内存、采用哈希表结构成为了设计时的基本要素。因为是独立的中间件读取数据要走网络虽然没有进程级缓存来的快但对比数据库而言性能十分客观~ 2.2、通过消息中间件削峰填谷 左眼跳财右眼跳灾。果然在不久之后系统再一次出现瓶颈小竹看着面如黑锅的老板再次对系统进行观察分析于是看到了类似下图的流量统计 系统在凌晨与深夜请求数会急剧下降而在中午时分请求数屡创新高小竹盯着这个顶点心里总有种莫名的熟悉感怎么回事仔细一回想哦原来是跟自己当初股票的买入点一样……
回归正题按理说引入Redis后就算高峰期也能抗住可为什么系统又不行了突然闹钟灵光乍现Redis只能分担读压力假设此时写并发也非常高数据库扛不住同样会造成系统瘫痪 再回过头来观察这张图很明显系统流量高峰期只集中在某段时间内图中框出来的位置而其余时刻流量正常特别是凌晨和深晚特别低流量会进入低谷期。既然系统并不是全天高峰期那能否想办法把高峰期的流量放到低谷期来处理呢这样即不会因为并发过高导致系统瘫痪同时还能充分利用空闲时间段的机器资源。
上面这个理念特别棒怎么落地难道高峰期的用户请求先记录下来等到半夜再处理返回吗显然不可以因为一个用户中午进行了操作结果半夜才响应产品经理能把你砍死……。有更好的方式吗当然有消息中间件MQ MQ有个核心作用就是削峰填谷可按前面的模式削峰行不通到底咋削想要削的合理首先得对业务做区分任何一个功能都可以分为核心步骤与辅助步骤比如下单链路中“提交订单、扣减库存”这类属于核心操作而“推送通知、生成交易快照”这些属于辅助动作按现有的模式一个下单请求会将整个链路上的操作都执行一次这里就会出现四个写操作插入订单数据、修改库存数据、插入通知数据、插入交易快照数据。
相信到这里大家心里就有数了削什么辅助操作在处理下单请求时只执行核心操作非核心操作直接往MQ中丢一/多条消息等待低谷期再真正执行写入操作。通过这种方式在目前案例中就减轻了流量高峰期一半的写入压力同时MQ除开能削峰填谷外还能对业务进行解耦以及实现异步处理加快单次请求链路的处理时间让请求响应速度更快用户体验感更佳~ 2.3、数据库集群 虽然通过Redis减轻了DB的读取压力通过MQ降低了写入并发可因为流量越来越大最终落入到DB的请求还是很多单库逐渐开始变得吃力小竹迫于无奈只能先走上“升配”的老路同时寻求其他解决之道……
小竹深思一番过后忽然灵光一动既然Java应用能做集群那数据库能否采用相同思想通过多台机器构建集群呢好像可以该怎么做好一点网上一搜发现了个概念叫读写分离毕竟所有流量都可被分为读、写两种那能否搞一个节点专门处理写入SQL另一个节点负责查询SQL呢当然可以负责处理读请求的节点只需及时同步最新写入的数据即可 为了保证主从库之间的数据一致性这里使用Canal来降低同步数据时的延迟无法保证零延迟通过这次架构调整后select语句走从库执行而写入类型的语句则走主库执行主从各司其职数据库的并发吞吐量爬上了新的阶级。 2.4、按业务划分子系统 经过前面多次架构调整后系统的架构却没有停止演进很快便迎来了新挑战随着业务越来越复杂、团队规模越来越大Git上的代码分支特别多搞到最后代码合并困难没办法只能将不同分支的代码独立运行因此逐渐出现业务分化在时间的推动下一个大的系统变成多个子系统共同执行系统架构变成了如下样貌以电商平台为例 经过不断迭代小竹最初负责的小电商项目逐渐演变成了商城子系统、交易子系统、物流子系统、营销子系统……等多个子系统。而进入系统的用户请求需要在网关配置路由规则从而实现不同子系统的流量分发而多个子系统之间通过WebServices、HTTP等方式调用对方接口来配合工作。
通过这种方式能让团队分工更加明确并且多个子系统之间互不影响提升了系统的分区容错性而且使得系统吞吐量进一步升高分布式/微服务理念的开始。 2.5、SOA架构 经过子系统的演变后其实整个系统已经初步变成了所谓的“分布式系统”但这种子系统拆分存在致命的缺陷多个子系统之间就好似一个项目里的多个模块产生了强耦合性系统之间的配合完全靠写死对方IP地址来完成调用一旦某个子系统出现故障依旧存在整个系统全面瘫痪的风险
同时这种强耦合的模式下系统拓展变得十分困难比如交易子系统扩容节点后另一个依赖于交易系统的第三方无法动态感知新节点的加入有人或许会说我们可以通过域名完成接口调用呀这的确是种解决方案但每次接口调用都需要经过域名解析进一步加大了接口响应时间性能堪忧于是在多种因素的影响下小竹必须对系统的整体架构再次进行调整怎么做基于SOA架构重构系统。 在SOA架构里有个新的概念ESB企业服务总线它是一个可复用的中央基础设施用于协调各分布式系统中各个服务间的通信和交互同时能够提供协议转换、消息转换、请求路由、系统集成……等一系列服务。
正是因为ESB总线的存在它成为了各系统间的粘合剂就算各系统的接口风格、数据交换格式、使用的协议等不一致ESB也能完美进行转换从而使得各系统能很好的交互并且可以使得各系统接口标准化各系统更易于维护/迭代。
除此之外基于SOA架构拆分的项目在性能出现瓶颈时各子系统可按需进行横向拓展比如交易系统承载的访问量较大可以针对该子系统拓展更大的集群对外提供服务。 2.6、分库分表 随着业务系统的壮大小竹发现传统模式的数据库再现颓废虽说能通过主从、多主等模式加以改善但不足以完全应对越来越大的流量冲击也无法承载大流量带来的海量数据存储需求且无法及时响应大表里的查询需求……
综上数据库架构的改造势在必行如何改既然业务系统可以拆成多个子系统那DB层能否如此当然可以我们可以针对不同的子系统抽出各自的业务表形成专属库而这就是所谓的分库分表-垂直分库思想。 与业务系统一样如果某个子系统的单个DB节点无法承载业务量时依旧可以横向拓展出多个节点对外服务以此应对随时增长的流量冲击与存储需求。而水平分库时究竟选择主从、多主还是分片模式大家可以根据实际情况来做抉择。
当然一旦将某业务的数据库横向拓展出多个节点时多数据源该怎么协调读写SQL又该落入哪个节点这就得引入Sharding-Sphere、MyCat这类分库分表中间件由它们来负责统一管理分库分表这里不做展开感兴趣的伙伴可参考分库分表实战篇。
分库分表后并不像传统的单主机数据库一样所有工作由数据库自身完成数据库只能在逻辑层被称为一个整体实际上已经演变成了“分布式数据库”以Sharding-Sphere里的Sharding-JDBC为例读写SQL则由Sharding进行分发写入时数据会被分散到不同节点存储查询时从多节点查询出的数据也由它来负责汇总聚合。
当然随着技术的发展如今也出现了许多例如TiDB、OceanBase……的分布式数据库它们既支持标准SQL的解析能力又天然支持分布式场景执行写入语句时自动分片存储执行标准查询SQL时会解析为分布式的执行计划而后分发到每个节点上并行执行最终由数据库自身汇总数据返回感兴趣的自行了解。 2.7、多层级负载 随着业务系统、数据库架构改造工作的落幕小竹本以为尘埃落地可谁曾料到整个系统的“咽喉要地-网关”竟然出现了问题Nginx负责接收所有入站流量并将其转发给内部系统处理而后处理出站流量此刻它却显得乏力面对来势汹汹的入站流量抗不住只能选择宕机……
好了如何平稳承接庞大的入站流量光靠Nginx依然不够我们可以照葫芦画瓢选择多负载模式在Nginx前面再架设一个负载器预算够可以选择硬件负载均衡器如F5、A10等如果预算不足则可以采用软件层面的负载器如LVS 通过LVS我们可以给Nginx搭建集群从而提升流量接入层的整体吞吐量类似于阿里云的SLB现CLB负载器底层亦是使用LVS技术进行构建。当然接入层还可通过DNS轮询解析、CDN分发等方式进行优化这里不做展开感兴趣的可参考之前《流量接入层设计》。 三、微服务云原生时代的演进 流量接入层、DB层的架构趋于平稳后再次将目光放回业务系统虽然之前基于SOA架构将整个复杂的系统拆分成了多个独立的子系统但是抽取时的粒度较大随着时间推移各个子系统又会变得臃肿彼此间依赖关系变得复杂。同时因为拆分粒度较大多个子系统之间会有不少重复功能如推送消息、权限验证等。最关键的是在SOA架构中ESB总线属于中心一旦ESB出现故障会导致整个系统无法正常运转。也正是此时市面上出现一种新的概念微服务 3.1、微服务架构改造 微服务从它的名称不难看出它的意思是指将整个业务系统拆分成一个个独立的微小服务每个服务专注某个特定的业务功能。而Java因为SpringCloud微服务框架的横空出世将微服务概念推至巅峰它继承了SOA架构的理念提供了API网关、服务治理、服务保护、服务调度、统一配置、RPC调用等一系列基础落地组件 在微服务架构中系统内的各项业务会划分出精细的服务而一些例如消息、鉴权、支付等基础功能亦可抽离出可复用的独立服务。此外非业务类的功能负载均衡/服务保护/消息转换/请求路由等不会像SOA架构中那般由ESB成为独裁者而是划分更为明确的各个组件如请求路由交给网关处理、服务保护交给断路器负责、负载均衡交给专门的负载器完成……
粒度更小代表服务节点数更多各个服务节点又可做集群拓展意味着后端架构不再受业务量增长的影响当业务增长/萎靡时可以通过动态伸缩节点来提供不同等级的吞吐量至此后端的整体架构趋向于稳定。 3.2、多样化存储 随着微服务架构的落地此时却出现了新的问题系统体量越来越大光依靠传统型数据库已无法支撑各种存储需求比如搜索场景在体量较小时咱们可以通过like之类的模糊查询手段实现而随着数据集变大、搜索场景多样化之前的手段已不再适用怎么解决搜索引擎。 当下较为流行的搜索引擎是ElasticSearch可以通过它来根据用户输入的关键字快速检索系统内的海量数据集。当然ES只是为了解决部分场景下的问题对于系统多样化的存储需求可能会用到各类存储组件如
文档数据库MongoDB、Neo4j等时序数据库InfluxDB、Druid、Kdb、Graphite、TimescaleDB等对象/文件存储云厂商的对象存储服务OSS、OBS、COS、S3等、HDFS、FastDFS、MinIO等大数据套件Hadoop、HBase、Cassandra、Hive等
针对不同的业务场景可以选用最适合的存储组件不同组件效果带来的效果差异很大举个大家都能理解的例子比如查询热点数据的场景如果单纯使用MySQL这类关系型数据库再怎么优化也很难实现毫秒级响应但如果选用Redis来存储热点数据毫秒级的响应速度简直不要太轻松~ 3.3、容器化时代 随着各种架构的改革落地系统内组件越来越多后端服务数量也越来越多同时还要考虑高可用为核心组件/服务搭建集群小竹很快迎来了新的痛苦硬件成本实在太太太高了就算一台机器同时部署几个应用也需要几十、上百台服务器…… 硬件资源开销大是一方面另一方面是运维困难几十上百种服务/组件相互交错代码管理、源码打包、环境部署、版本发布、版本回退、故障恢复……稍微搞错一步就会发现整个系统跑不起来这种体验简直令人痛不欲生而正是此时一种新的技术出现在大众视野虚拟化容器。 虚拟化容器解决了资源问题而系统部署工作依旧困难因为流程又多又复杂光依靠人工很容易出错此时迫切需要一种自动化部署技术来介入处理而恰巧正在此时大名鼎鼎的KubernetesK8S降世它与Docker形成了完美的互补关系Docker提供基本的创建、启动、停止和重启等容器化功能K8S则提供了更高级的功能如容器的自动部署、自动扩缩、滚动升级、灰度发布、节点自愈等并支持在多个节点上运行容器还额外提供了负载均衡、服务发现等功能面对庞大且复杂的微服务系统可以使用K8S实现容器的编排和管理
到这里系统部署工作依旧没有完全实现自动化这里缺乏了最关键的一步代码管理与打包所有系统并非一开始就能达到“稳定态”几乎任何一个程序都会经过N多次迭代更新不可避免的会多次更新代码。如果每次更新后需要手动打包成镜像这同样会增加出错风险这一步能否自动化答案是可以有个工具叫Jenkins。 Jenkins配合Git的触发回调可以实现代码更新时自动拉取最新代码并打包生成新镜像多分支并行开发的情况开发人员也只需在Jenkins上进行操作几乎实现了全自动化部署流程。当然整个完整流程有个专业的叫法CI/CD可持续集成/持续部署。 CI/CD的全流程由GitJenkinsDockerK8S配合实现四者缺一不可用类似的产品代替可以大致的完整流程如下
①开发人员将代码提交到Git远程仓库Git上的webhook会触发Jenkins构建②Jenkins通过Docker构建镜像完成后并将镜像推送到Docker仓库③K8S从Docker仓库拉取最新的镜像并自动部署到系统集群。
越是大型的系统通过CI/CD技术更能为开发团队提供高效、自动化的产品开发和部署流程。至此小竹再也无需担心部署方面的问题。 3.4、云原生时代 上阶段提到的DockerK8S部署方案是一种典型的微服务上云的方式通过这种方式可以充分利用云计算的优势通过K8S实现集群管理、自动化部署、动态伸缩、容错处理等功能从而更好地支持业务的发展和创新。 PS自己从零搭建私有云的成本很高所以才出现了各大云厂商中小项目可以借助这些公有云实现微服务上云也不需要自行维护云平台本身的问题。并且可以借助云平台的强大功能满足各场景下的需求例如中小电商平台大促活动前可升配资源活动结束后再降配~ 但随着云计算的不断发展现如今出现一种名为“云原生”的概念云原生是一种构建和运行程序的新方法旨在实现应用与基础设施资源之间的解耦让开发人员更关注业务本身这是啥意思呢
大家想想如今的微服务架构中除开我们编写的业务服务外系统内是不是还会存在许多基础设施如网关、断路器、负载均衡器、注册中心等等这些组件是每个微服务开发者需要考虑、甚至介入开发的而云原生的内在含义是指开发人员以后老老实实负责写业务就行像这类基础设施组件你直接用我提供的因为云环境中自身就提供了这些功能如K8S就有负载均衡、服务发现等功能。 云原生的核心是将应用程序设计成云环境的原生应用即在系统设计之初就考虑到应用程序将运行在云环境中并以后不会脱离云环境独立运行服务注册、API网关、服务保护……等一系列设施全都用云环境里自带的比如直接把服务注册到K8S不再单独部署Nacos这类组件。 PS虽然如今很多微服务项目都已经上云了但很少有项目转到云原生环境因为想要构建云原生程序必须全面拥抱云环境老项目需要推翻之前的架构重新变革并且后续必须得一直运行在云原生环境中。 3.5、异地多活架构 这里是题外话异地多活架构是出于高可用、高性能的目的出发从而衍生出的一种技术架构。正常来说一个系统不管有多少组件/节点通常只会部署到一个地区机房而早年由于这样的部署模式机房出现灾难时如火灾、断电、洪水、断网等会导致整个系统无法访问而异地多活架构就因此而来。 异地多活指的是在不同城市/地区各自部署一套系统当某个城市的机房出现故障时用户请求依旧可以访问另一个地区的服务从而保证系统达到99.9…%高可用性。同时还可以借助智能DNS解析技术实现就近分发比如上海、杭州两地部署了应用现实距离上海近的用户则将请求解析到上海机房处理杭州同理这样可以加快用户的访问速度CDN的原理类似。 总结
从整篇内容来看架构的演进似乎是一帆风顺的每遇到新问题总有新的技术栈应运而生巧妙地化解了现有的技术难题。然而若从历史的角度审视每次系统面临新的挑战时解决过程并非如此轻松。许多新技术栈在初期可能鲜有人涉足需要一步步去踩坑、填坑直至最终投入生产环境。
如今我们所面对的众多挑战之所以能有如此丰富的技术栈供选择是因为历史上有无数“先行者”为我们铺平了道路是他们帮我们把坑填平了若有一天你也成为了这样的“先行者”面对前所未有的问题没有现成的解决方案可以参考时你或许也需要独自琢磨甚至可能需要从零开始研发全新的组件来攻克~
其实大家看完这篇文章也能发现一个技术发展的规律回顾十年前曾经风靡一时的“技术栈”如今却难寻踪影呈现在我们面前的则是全新技术为啥这是因为技术发展会跟随业务技术为业务提供服务业务推动技术发展两者相辅相成彼此成就。
