自建网站的优缺点,网站自适应怎么做,郑州网站建设知名公司,网页制作收费吗本周和大家聊聊架构进化史-大家可文末扫码加入随着互联网持续高歌猛进#xff0c;相关技术名词也是层出不穷#xff0c;ServiceMesh服务网格这两年尤为火爆#xff0c;然而很少有讲清楚的文章。笔者这里用心整理了一篇文章#xff0c;用11张图演绎ServiceMesh的进化历程相关技术名词也是层出不穷ServiceMesh服务网格这两年尤为火爆然而很少有讲清楚的文章。笔者这里用心整理了一篇文章用11张图演绎ServiceMesh的进化历程由浅入深老少咸宜欢迎拍砖01PART单体应用万丈高楼平地起要理解高端ServiceMesh得先从单体应用架构开始。在没有那么多架构概念的“远古”年代一个网站项目的全部功能都是在一个进程的一个B/S应用架构应该是这样的BS应用架构当用户访问量变大导致一台服务器无法支撑时怎么办呢加服务器加负载均衡架构就变成这样了B/S负载均衡后面发现把静态文件独立出来通过CDN等手段进行加速可以提升应用的整体响应然后架构就变成B/S前后端分离然而上面3种架构都还是单体应用只是在部署方面进行了优化所以避免不了单体应用的根本缺点· 代码臃肿应用启动时间长代码超过1G的项目都有· 回归测试周期长修复一个小bug都需要完整的回归测试· 应用容错性差某个小小功能的程序错误可能导致整个系统宕机· 伸缩困难单体应用扩展性能时只能整个应用进行扩展· 开发协作困难一个大型应用系统可能几十个甚至上百个开发人员大家都在维护一套代码的话代码管理复杂度急剧增加。02PART微服务这个时候微服务诞生了微服务架构将单体应用拆解成多个小粒度的微服务 (micro-service)通过HTTP API来组装对外提供服务。由于每个微服务足够小且功能内聚因此能很好地解决以往单体应用的开发与发布困难的问题。微服务架构的核心是为了解决应用微服务化之后的服务治理问题。一个微服务如何发现其他微服务呢最简单的方式就是每个微服务里面配置其他微服务的地址但是当微服务数量众多的时候这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件服务注册中心所有服务都注册到服务注册中心同时也可以从服务注册中心获取当前可用的服务清单服务注册中心解决服务发现问题后接着需要解决微服务分布式部署带来的第二个问题服务配置管理的问题。当服务数量超过一定程度之后如果需要在每个服务里面分别维护每一个服务的配置文件运维人员估计要哭了。那么就需要用到微服务架构里面第二个重要的组件配置中心微服务架构就变成下面这样了配置中心以上应用内部的服务治理当客户端或外部应用调用服务的时候怎么处理呢服务A可能有多个节点服务A、服务B和服务C的服务地址都不同服务授权验证在哪里做这时就需要使用到服务网关提供统一的服务入口最终形成典型微服务架构典型微服务架构上面是一个典型的微服务架构当然微服务的服务治理还涉及很多内容比如· 通过熔断、限流等机制保证高可用· 微服务之间调用的负载均衡· 分布式事务2PC、3PC、TCC等· 服务调用链跟踪等。03PARTSevice Mesh随着业务的发展和微服务化的深入微服务架构里面的各种服务治理反而会成为前进的桎梏因为技术门槛太高大量企业无法推进下去。于是Service Mesh诞生了以LinkerdEnvoyNgixmesh为代表的代理模式边车模式应运而生这就是第一代Service Mesh它将分布式服务的通信抽象为单独一层在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能作为一个和服务对等的代理服务和服务部署在一起接管服务的流量通过代理之间的通信间接完成服务之间的通信请求。如果我们从一个全局视角来看就会得到如下部署图如果我们暂时略去服务只看Service Mesh的单机组件组成的网络何为Service Mesh服务网格这会儿大家应该理解了然后为了提供统一的上层运维入口Service Mesh演化出了集中式的控制面板所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下至此11张图见证了单体架构到微服务到服务网格的变迁展示了Service Mesh到底是什么以及是如何一步步演化到今天这样一个形态。这两年还有很多热门的技术名词如中台、Severless、Faas、CloudNative让996的程序员们各种懵。技术演进浩浩荡荡顺之者昌逆之者亡追逐高薪必须直面本周三(9号).NET社区邀请了重磅大咖(本文贡献者之一)在线分享《这些年的互联网架构进化史》欢迎大家扫码进交流社群扫码即可加入 添加微信 zhaoxiNET007
