系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。
子系统:子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分。子系统的定义和系统定义是一样的,只是观察的角度有差异,一个系统可能是另外一个更大系统的子系统。
以微信为例来做一个分析:
模块和组件都是系统的组成部分,只是从不同的角度拆分系统而已。例如:
例如我们要做一个学生信息管理系统,这个系统从逻辑的角度来拆分,可以分为:登录注册模块、个人信息模块、个人成绩模块;从物理的角度来拆分,可以拆分为应用程序、 Nginx、Web 服务器、MySQL等
服务是可以单独运行,并且对外提供功能的一种形式。可以将一个复杂的项目分解成多个服务。当某一个服务挂掉时不会拖垮整个系统。如果没有服务化,每当一个新的功能被添加到系统中就会影响到所有功能;如果采取服务化,每个服务只对其上下游的服务负责。
在软件工程中,耦合指的就是对象之间的依赖性。对象之间的耦合度越高,维护成本越高。因此对象的设计应使类和构件之间的耦合最小。软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准。划分模块的一个准则就是高内聚低耦合。
耦合性存在于各个领域,而非软件设计中独有的,理论上说绝对的零耦合是做不到的,但可以通过一些方法将耦合降至最低,降低耦合度即可理解为解耦,在设计上解耦的核心思想是【彼此独立,互不依赖】。
分层结构是最为流行、应用最广泛的应用软件的设计方式。在应用了分层结构的系统中,各个子系统按照层次的形式组织起来,上层使用下层的各种服务,而下层对上层一无所知。每一层都对自己的上层隐藏其下层的细节。
经典三层架构:
在软件架构中,经典三层架构自顶向下由用户界面层、业务逻辑层、数据访问层组成。在提出该分层架构的时代,多数系统往往较为简单,本质上都是一个单体架构的数据库管理系统。这种分层架构有效地隔离了业务逻辑与数据访问逻辑,使得这两个不同关注点能够相对自由和独立地演化。经典的三层架构如下所示:
分层的设计原则是:保证同一层的组件处于同一个抽象层次。即所谓的“单一抽象层次原则”。这一原则可以运用到分层架构中。比如下图所示:
假设我们有一个程序,它在逻辑上有一些不同的对象,并且这些对象彼此之间会相互交流。
在一个类中,当每个对象的状态保持相对孤立,就实现了封装。其余的对象并不能观察到这个对象的状态。他们能做到的只有调用一些被称作“方法”的通用功能。
因此,对象使用方法掌控着自己的状态,除非明确允许,没有其他人可以接触到它。如果你想和某个对象交流,你需要使用提供的方法。但在默认情况下,你无法改变对象的状态。
架构图是为了表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界,以及软件系统的物理部署和软件系统的演进方向的整体视图。要让干系人理解、遵循架构决策,就需要把架构信息传递出去,架构图就是一个很好的载体。不同的视角和角色,关注点也是不同的,看到的架构图是不一样的。
使用者:CEO、CIO、CTO、产品总监
核心业务流程:
核心能力:
使用者:产品总监、产品经理
示例: 黑马头条功能架构图
使用者:系统架构师
使用者:系统架构师
示例一:https://www.processon.com/view/5f2a0bfb1e08533a629b7ed3
示例二:冷链项目技术架构图
使用者:CTO、系统架构师、数据架构师
示例一:数据模型
示例二:大数据平台架构
使用者:运维架构师
示例一:https://www.processon.com/view/5f2a03cf637689168e49e3fa
示例二:冷链项目部署架构图
公司发展的初期,资金少、用户少,需要的软件产品的数据和并发量都比较小,这个时期大多数的软件系统只需要单一服务器就可以满足需求,所有的业务逻辑都在单一应用系统,单应用、单数据库。数据库部署在和应用相同的虚拟机或服务器上,或者放置在另外一台机器上。此时的架构图如下:
或
这种架构模式优点很明显:
随着公司和业务进入快速发展时期,软件系统面临来自多方面的考验:
单体架构的缺点也越发的凸显出来:
单体架构有着明显的缺陷,随着系统访问量的增多,这些缺陷越来越凸显,为了解决这些缺陷,架构升级了,变成了分布式架构。分布式,就是多个实例提供服务。下面我们来简单介绍下常见的一些解决方案。
架构优点:
缓存分为多级缓存,比如本地缓存(JVM中),分布式缓存服务器(Redis集群等)。本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务。常见缓存服务器包括Redis、Memcached等。使用缓存后,数据访问压力得到有效缓解。
业务进一步发展,用户越来越多,系统又出现了瓶颈,此时整个电商系统可以做系统拆分了,系统拆分分为水平拆分和垂直拆分。
水平拆分:
拆分成商品、订单、交易、用户、支付等多个系统,每个系统都都是多台服务器构成的集群。
垂直拆分:
将一些公共业务和服务,如用户中心拆分成注册登录中心和用户中心,短信、文件、消息等各种公共服务,从业务系统中拆分剥离出来。
这种架构的优势也比较明显,一方面,应用系统增加了,能够响应用户的请求也会变多,另一方面公共服务能够提供给所有的应用使用,达到服务复用的效果。但是大家需要注意的是数据库有可能只是一个,而单一数据库服务器的处理能力必然是有限的,随着用户并发量的持续增多,数据库将会是系统的瓶颈。
读写分离:
在网站的用户达到一定规模后,数据库因为负载压力过高而成为网站的瓶颈。目前大部分的主流数据库都提供主从热备功能,通过配置数据库的主从关系,可以将一台数据库服务器的数据更新同步到另外的数据库服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。
应用服务器在写数据的时候,访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库,这样当应用服务器读数据的时候,就可以通过从数据库获得数据。
分库分表:
随着数据库中的数据量越来越大,相应的,查询所需要的时间也越来越多,这个时候,相当于数据的处理遇到了瓶颈,另一方面单库发生意外的时候,需要修复的是所有的数据,而多库中的一个库发生意外的时候,只需要修复一个库。基于此,分库分表就成了必然。分库分表的策略很多,如按照用户、订单、交易、商品等进行分库,不同的数据库中按照时间进行分表。
分库分表带来性能上的显著提升,但相应的管理和维护成本也比较高,比如数据库服务器的维护、分表策略的维护。为了便于应用程序访问分库分表、读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,使数据库的分库分表和读写分离对应用透明。
随着网站业务不断发展,用户规模越来越大,和中国复杂的网络环境,不同地区的用户访问网站时,速度差别也极大。为了提供更好的用户体验,留住用户,网站需要加速网站访问速度。主要手段有使用页面的静态化和CDN。
操作方式上把一些页面,比如某些商品的详情信息,在发布商品时将页面静态化,静态化页面和静态资源可以放在CDN服务器,部署在网络服务提供商的机房,用户在访问静态资源时,可以很好的利用CDN的优点,从距离自己最近的网络提供商机房获取数据。
应用之间的服务存在互相调用的情况,但有些场景下,并不需要同步调用,比如某个业务完成后,需要短信通知对方,而短信接收的时间晚几秒钟都是可以接受的,此时就不需要同步处理了,我们可以使用消息队列,把发送短信的内容扔到消息队列中,达到异步处理的效果,从而增强业务系统的性能,此时对于服务之间也达到了解耦的功能,服务之间的依赖减少了。
微服务架构是分布式架构的深化,分布式架构偏向于部署和环境,比如上边提到的应用、数据库、缓存等,在多台机器上进行部署,就属于分布式。微服务架构通过业务拆分实现服务组件化,通过组件组合快速开发系统,业务单一的服务组件又可以独立部署,使得整个系统变得清晰灵活。
大量的分布式服务又使得架构实现面临问题,如服务注册发现,服务统一接入和权限控制,服务的负载均衡,服务配置的集中管理,服务熔断,服务监控等。
所以微服务架构是由这些基础的服务组件和业务微服务组件共同组成:
采用微服务架构后,项目可以快速迭代与持续交付。但是也带了一些弊端,开发人员除了需要关注业务逻辑实现外还需要考虑业务的一系列问题,比如服务注册,服务发现,服务通讯,负载均衡,服务熔断,服务超时等,这些是非常重要的。大多数时候,我们需要依赖第三方库或者组件来提供这些服务,例如Hystrix,Eureka、Zookeeper等组件,在其服务组织中起到了广泛的应用。
传统企业或者很多企业的软件,大多不止一套系统,都是各个独立大系统的堆砌。整体存在的问题是:
非常容易能够想到,解决这些问题的方法是:组件化、服务化。
微服务架构,将各个组件或者模块分散到各个服务中,对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。什么是组件化?
组件化,即将一个大系统,按照一定的业务或者技术维度,拆分成独立的组件。目的是为了分而治之,为了可重用,为了减少耦合度。比如按照技术维度:文件上传下载组件、短信发送组件、搜索组件、缓存组件;按照业务维度:用户中心、商品中心、支付中心等。
阿里巴巴提出 大中台,小前台战略,就是把组件化、插件化、服务化解决方案到极致。通过产品线公共业务或者技术下沉,形成各种技术中台或者业务中台。
有利必有弊,服务化也会面临很多问题:
预告:下一篇我们聊聊那些奇怪的需求
如果觉得内容不错的话,希望大家可以帮忙点赞转发一波,这是对我最大的鼓励,感谢🙏🏻
END