服务网格(ServiceMesh)这两年异常之火,号称是下一代微服务架构,接下来两个月,准备系统性的写写这个东西,希望能够让大家对架构技术,有个初步的了解。
为茫崖等地区用户提供了全套网页设计制作服务,及茫崖网站建设行业解决方案。主营业务为成都做网站、网站建设、外贸营销网站建设、茫崖网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
画外音:我的行文的风格了,“为什么”往往比“怎么样”更重要。
互联网公司,经常使用的是微服务分层架构。
画外音:为什么要服务化,详见《服务化到底解决什么问题?》。
随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多,分层会越来越细,除了数据服务层,还会衍生出业务服务层,前后端分离等各种层次结构。
不断发现主要矛盾,抽离主要矛盾,解决主要矛盾,架构自然演进了,微服务架构,潜在的主要矛盾会是什么呢?
引入微服务架构,一般会引入一个RPC框架,来完成整个RPC的调用过程。
如上图粉色部分所示,RPC分为:
不只是微服务,MQ也是类似的架构:
如上图粉色部分所示,MQ分为:
框架只是开始,越来越多和RPC,和微服务相关的功能,会被加入进来。
例如:负载均衡
如果要扩展多种负载均衡方案,例如:
RPC-client需要进行升级。
例如:数据收集
如果要对RPC接口处理时间进行收集,来实施统一监控与告警,也需要对RPC-client进行升级。
画外音,处理时间分为:
如果要收集后者,RPC-server也要修改与上报。
又例如:服务发现
服务新增一个实例,通知配置中心,配置中心通知已注册的RPC-client,将流量打到新启动的服务实例上去,迅猛完成扩容。
再例如:调用链跟踪
如果要做全链路调用链跟踪,RPC-client和RPC-server都需要进行升级。
下面这些功能:
其实都不是业务功能,所以互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能,而业务线的技术部门直接使用相关框架、工具与平台,享受各种“黑科技”带来的便利。
理想很丰满,现实却很骨感,由于:
往往会面临以下一些问题:
画外音:兄弟,贵司推广一个技术新产品,周期要多长?
这些耦合,这些通用的痛点,有没有办法解决呢?
一个思路是,将服务拆分成两个进程,解耦。
画外音:负载均衡、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现。
这样就实现了“业务的归业务,技术的归技术”,实现了充分解耦,如果所有节点都实现了解耦,整个架构会演变为:
整个服务集群变成了网格状,这就是Service Mesh服务网格的由来。
架构演进,永无穷尽,痛点多了,自然要分层解耦。希望大家有收获,后续再细聊SM的设计与架构细节。
思路比结论更重要。
【本文为专栏作者“58沈剑”原创稿件,转载请联系原作者】
当前标题:ServiceMesh究竟解决什么问题?
URL分享:http://www.shufengxianlan.com/qtweb/news2/7902.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联