互联网系统面临怎样的挑战?

发布于: 20 小时前
互联网系统面临怎样的挑战?

随着互联网技术的发展,尤其是微服务技术和理念的普及,构建一个互联网系统已经不是难事,但要是不断支撑业务的发展,就需要系统有好的品质要求:可扩展,高性能、高可用等等。看见一个好的技术架构不只要满足功能要求,而且还有满足品质要求。

好的架构

好的互联网产品也都是慢慢运营出来的。比如淘宝刚开始也是花费3000美元买的一个网站,技术架构LAMP架构也是比较简单的,随着业务规模的增长,不断地解决发展中的问题,而成长起来的。

但往往我们上来并不能保证一定能够设计出良好的架构,而是往往需要经过几次迭代才趋于稳定。原因就在于:领域的需求理解是需要一个过程的,对客户需求的理解不可能一蹴而就。

要是一个足够好的架构,肯定要满足以下几个要求:

  • 支持增量式的构建

  • 经过时间考验的架构

  • 让各个相关方满意(开发、测试、用户等)

技术方向

由此可见业务规模所带来的大流量,高并发是因。要支持高并发就应该做到可扩展、高性能、高可用。

应对高并发有2个技术发展方向:

1、垂直伸缩

实施简单,升级服务器即可,可能花钱太多

缺点:

  • 达到某个程度后,增加计算能力需要更多的花费

  • 单个机器的性能是有物理极限

  • 操作系统的设计或用用程序自身制约

2 、水平伸缩

通过增加服务器提升计算能力的一类架构方法

被认为是伸缩性的圣杯,可以克服垂直伸缩带来的单位计算成本随计算能力增加而迅速飙升的问题

另外,可以增加更多的服务器,这样,就不会像垂直伸缩那样遭遇到的单台服务器的极限。

所以需要架构设计。

技术架构的演化

单体架构

特点:

1、所有的功能集成在一个项目工程中。

2、所有的功能打在一个war包部署到服务器。

3、通过部署应用集群和数据库集群来提高系统的性能。

优点:

1、项目架构简单,前期开发成本低,周期短,小型项目的首选。

2、开发效率高,模块之间交互采用本地方法调用。

3、容易部署,运维成本小,直接打包到web容器即可运行。

4、容易测试,无依赖,在本地就可以启动调试完整的系统。

缺点:

1、全部功能集成在一个工程中,对于大型项目不易扩展及维护。

2、版本迭代速度逐渐变慢,修改就要将整个应用全部编译。

3、无法针对某业务按需伸缩。

SOA架构

特点:

1、基于SOA的架构思想,将重复公用的功能抽取为组件,以服务的方式向各各系统提供服务。

2、各各系统与服务之间采用webservice、rpc等方式进行通信。

3、ESB企业服务总线作为系统与服务之间通信的桥梁。

优点:

1、将重复的功能抽取为服务,提高开发效率,提高系统的可重用性、可维护性。

2、可以针对不同服务的特点按需伸缩。

3、采用ESB减少系统中的接口耦合。

缺点:

1、系统与服务的界限模糊,会导致抽取的服务的粒度过大,系统与服务之间耦合性高。

2、虽然使用了ESB,但是服务的接口协议不固定,种类繁多,不利于系统维护。

微服务架构

特点:

1、服务层按业务拆分为一个一个的微服务。

2、微服务的职责单一。

3、微服务之间采用RESTful、RPC等轻量级协议传输。

4、有利于采用前后端分离架构。

优点:

1、服务拆分粒度更细,有利于资源重复利用,提高开发效率。

2、可以更加精准的制定每个服务的优化方案,按需伸缩。

3、适用于互联网时代,产品迭代周期更短。

缺点:

1、开发的复杂性增加,因为一个业务流程需要多个微服务通过网络交互来完成。

2、微服务过多,服务治理成本高,不利于系统维护。

serverless架构

优点:

屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等),服务只用关注业务逻辑;

真正的与语言无关,服务可以用任何语言编写,只需和Service Mesh通信即可;

对应用透明,Service Mesh组件可以单独升级;

缺点:

Sidecar-存在资源占用、维护成本增加等缺点,在某些情况下可能并不合适:

边缘网络,IoT场景:资源非常有限,不适合启动太多Sidecar

FaaS场景:应用自身足够轻量,甚至比Sidecar还要轻量

Serverless场景:Scale to Zero时,对冷启动速度有严格要求,Sidecar的启动和初始化可能拖累应用启动速度

多运行时架构:

优点:

业务逻辑和越来越多的分布式系统问题之间的松耦合,同时解决了serverMesh中sidecar过多维护困难的问题。每个微服务由至少2个业务逻辑运行时和Mecha运行时构成。

缺点:

进程间通信- 部署在同一台主机,获得低延迟

复杂度 -混合式开发技能

通过mecha的 把传统的中间件这样的类库或组件,转移到平台级别,通过进程外的这种模型, 以多运行时的方式对应用提供扩展,而我们的 应用只关注业务本身,只需要编写业务逻辑就可以了,以获得各种分布式需要的超能力。。。

架构模式

这个架构模式是对微服务系列的架构还保持活力,等serverMesh以及mecha的流行,技术架构也会越来越简单,我们拭目以待。

“生产力决定生产关系,生产关系对生产力有反作用力。”

由此可见,未来随着技术架构的发展(生产力),我们实现业务也越来越简单(生产关系),这种作用也越来越明显,社会进步也会越来越快。

用户头像

ashuai1106

关注

还未添加个人签名 2017.10.20 加入

还未添加个人简介

评论

发布
暂无评论
互联网系统面临怎样的挑战?