微服务的架构,大多可能只会想到我们把业务拆分成一个一个互相协作的服务“模块”,但是并非那么想当然地这么简单,这里我先不谈业务拆分的复杂性,因为它足够需要很多文章来分析了,我的后续文章会跟上,我这里先从执行架构角度来分析微服务的基础设施、通信以及应用框架的各种考量和思考。 如果按照传统的方式: 去做,比如上面的架构:
明显我们不得不在这有限的机器中不停的取舍和决策,更加可怕的是物理的资源数量限制了我们架构的设计思路,这反过来是限制我们平台的发展的,如果添加新的东西,也会影响其他已有的部分,真是狗血!居然让硬件限制了我们的想象力!怎么办呐?另外还有硬件水平拓展无法自动管理、容灾治理等等的问题,还有服务自理的问题,应用部署的问题等等,如何搭建基础设施以便简化日后的升级、维护和获得高可用性? 先给一个整体架构: 建议先不要做微服务(SAAS)这一层,先将物理机、网络、存储进行虚拟化,这一层提供IAAS的能力,这里推荐openstack来做这个事情,因为它非常成熟并且社区、文档齐全,但是它的设计是要涵盖所有业务场景,所以组件非常庞大,所以要用openstack的话,先要做减法并和其他组织内因素做平衡: 1. 成本:财务问题对任何组织来说都是头等大事,可能我的决策最终会死在这个上面,因为CEO可能会卡我的脖子。所以需要先设计一个通用性的方案,以此为基准设计其他类型的架构,比如计算型(给大数据用的)、业务型的等等,有了基准,成本核算相对容易。最后,一个很靠谱的建议就是不必使用openstack所有的组件(这一点请查看官方的文档),做出一个最小化、简单、可用的集群架构就可以了,先up上去,然后慢慢添加资源,成本则为可以控制的,并且是有依据的添加资源。 2. 上线时间:如果都把时间用在了搭建IAAS上,明显项目就要完蛋,因为老板给的时间是有要求的,所以也是上面提出来的要先建立最小化、简单、可用的集群的原因,并且长远来看,IAAS基础设施为减少后期在基础上花的成本是有很大好处的。 3. 受利益空间:将来还可以将业务产品云化,变成公众产品变现,这是一个挺好的想法,峰值底下的时段,让外部用户也可以接入他们的应用,变现对超出预算的硬件投资是个很好的补偿措施,说不定会变成一个新的生意,这是公司喜欢看到的结果。 4. 技术因素: 规划计算资源容量 当设计计算资源池时,有很多情形会影响到用户的设计决策。例如,和每种hypervisor相关的处理器、内存和存储仅仅是设计计算资源时考虑的一个因素。另外,将计算资源用户单一的池还是用户多个池也是有必要考虑的,我们建议用户设计将计算资源设计为资源池,实现按需使用。一个计算设计在多个池中分配资源,会使云中运行的应用资源利用的最为充分。每个独立的资源池应该被设计为特定的类型的实例或一组实例提供服务,设计多个资源池可帮助确保这样,当实例被调度到hypervisor节点,每个独立的节点资源将会被分配到最合适的可用的硬件。这就是常见的集装箱模式。 使用一致的硬件来设计资源池中的节点对装箱起到积极作用。选择硬件选择硬件节点当作计算资源池的一部分最好是拥有一样的处理器、内存以及存储类型。选择一致的硬件设计,将会在云的整个生命周期展现出更加容易部署、支持和维护的好处。 OpenStack支持配置资源超分配比例,即虚拟资源比实际的物理资源,目前支持CPU和内存。默认的CPU超分配比例是16:1,默认的内存超分配比例是1.5:1。在设计阶段就要想要是否决定调整此超分配比例,因为这会直接影响到用户计算节点的硬件布局。 但是最终的问题是,任何合理的设计在经过一段时间之后就变得不合理,原因是业务的发展以及外部用户使用频率、方式的变化导致容量规划退化了,所以需要做阶段性的计划,不断根据监控反馈的负荷增加物理硬件或者调整执行架构(物理拓扑)! 网络虚拟化规划: 也就是所谓的SDN,IAAS的成败大都集中于此,网络通则一切都通,网络虚拟化包括链路虚拟化、路由器虚拟化、交换机虚拟化等等(具体如何做虚拟化大家可以查看Openstack的具体做法即可),举一个现实中的例子,日前有个飞机场的路由器挂掉了,结果整个服务不可用,飞机全部停飞,这个损失可是够大的! 如果我们虚拟化了网络,并且在物理层提供多台路由器做冷备,那么当主路由器挂掉的时候,虚拟网络可以为我们切换到一台备机上,服务就不会间断!网络规划是个细活,我建议第一层网络作为外部API访问使用,第二层作为管理网络,用于管理员部署VM、监控等使用,第三层内部通信网络,作为内部节点和服务通信的网络。这样划分之后流量在专属网络中流淌,不会互相影响,也最大减少网络风暴的影响程度。 存储虚拟化规划: 传统的方式是一组机器负责数据库服务,一组服务应用服务器,但是数据库系统的底层是基于文件的,也就是说数据库服务器的根本结构是上层的数据库引擎 数据文件,如果数据文件都存储在这一组机器上,明显浪费了其他机器的资源,不过这只是一个例子哈,不要对号入座! 我们虚拟化存储,就可以磨平大集群的存储的文件存储策略,有存储虚拟化组件管理文件存储,文件可能存储在任何一个地方,上层设施不必关心,但是需要采用何种存储虚拟化方案,是需要考量的,比如LVM还是cinder,另外就是我们需要把计算和存储虚拟化在同样的物理节点上,形成所谓“超融合架构”,最大化物理机资源的利用! 综上我们会有这样一个适当可控的规模、简单、可用的IAAS架构出来:
当然亲的openstack实施更需要谨慎从事,以上的架构建议,您可以在一个隔离的最小化硬件集群中作实验,一步一步验证,逐步建立一个恰当的IAAS,openstack的组件太多了,并且还在发展,所以给您的建立就是先要做减法,分步实施! 接着,我们有了IAAS之后,就相当于我之后很少考量物理层的问题了,它为我们的CAAS云保驾护航,我们所要做的是针对N个VM来考量(不可能是N个,越多可能越慢,这个需要一个规划的红线,主要是监控要跟得上去)我们的CAAS的架构,这样就极有很少的限制了微服务架构的发展! 我们在IAAS上加入容器云之后,就有这样的一个私有云能力平台架构了(有关CAAS应当具备哪些能力,后面有表格说明):
接下来,我们先把CAS-k8s本体放在一旁,我们来看看应用架构,它也影响了我们对CAAS设计的决策,正所谓业务驱动技术,这一点有一定道理! 假设我们现在有这样一个传统应用架构(烟筒型应用): 情形一:单一块状设计和部署方式 情形二:比第一种好一些 因为单元功能被解耦了,但是依然是整体化单一化部署模式,无法很容易的拓展,性能弹性也比较差,开发缠绕也比较厉害,开发不得不得依赖于模块关系,整体系统无法做到性能和容灾和合理的分布。 情形三:比之前的都好
单个服务器挂掉,还有另外几个!上了新服务器,手动改一下配置表….. 一看监控,同时只有一个服务器在提供工作,单进程Web服务器程序无法充分利用系统资源!成本越来越高! 情形四:SOA! 这个接近很优的情况了,为什么哪?因为SOA将业务拆分出来,并且每个进程一个承载一个SOA服务,很像我们之后要做的微服务架构,每一个服务自治发展不会影响其他服务的设计、高度容错、提供弹性!
但是与我们将来的微服架构有什么差别哪?微服务更加讲求较小的业务API粒度、内建环境自治、异构技术栈,可以说它是更加灵活的SOA:
前面说了我们有个IAAS,用openStack实现了,我们决定paas用CAAS作为PAAS层,为我们的微服务业务框架提供基础环境(有关CAAS-k8s提供的分布式和服务治理能力,请参考后面的表),这样我们就有了一个完整的运行时治理环境,接下来可以考虑业务架构了,不过我这里要提醒一下:
假设我们将来有一个微服务业务架构: 一个框代表一个微服务,红线代表调用关系,和SOA很类似,我们看一下某一个微服务块中的治理结构:
基础业务服务需要考量它的通用性,上层服务基本都是功能编排和流程编排,我们拿商品中心基础服务为例子,来说明基础服务的设计(这里就不画图了,这个具体业务细节相关,不过下面给出思路):
总结出思路:
以上种种实现了基础服务的通用性。 我们再深入下去,看一下更细的基础服务实现架构: 1. 因为上层业务服务应该向稳定的一方依赖过去,防止业务变化的扩散化,所以我们考量在基础服务上采用命令与查询分离的架构,具体如下: 写侧:
读侧:业务数据查询引擎的设计: 记得前篇的一片文章分析过,我们如果不把查询做得更加通用,就会有一个尴尬的局面,1:1针对业务设计查询的话,那就是会有API膨胀的问题,您的架构这会朝不保昔,逐渐腐化,所以查询部分要设计成“逻辑后推”模式,做成查询引擎,基本结构如下: 有人可能会问,为什么基础服务会这么设计?这里隐藏着好几个维度的考量:
因为有了基础数据微服务层,上层就不需要考虑太多有关数据的事情,专心关注功能和流程编排的设计和开发。 为了开发落地,需要设计和开发一种应用框架,提高应用或者业务开发效率,减少开发人员风格以及思想不一致导致的错误(这个进程内模型,以及进程间通信模型,采用SpringMVC拓展而来,如果有人对框架感兴趣,我有现成的源码,我自己开发的):
有了以上这套东西,基本上可以解除业务变化快、修改频繁、业务开发人员容易出错等等的问题,不过世界没有银弹,必须要不断改进和沉淀才可以! 其实实际情况要设计一个电商是超级复杂的,所以上面的例子只是为了说明微服务业务架构的一种思路罢了,具体情况还得具体分析。 但是仅仅在应用级别上有一套框架,依然解决不了很多问题的,我们需要有一套业务服务治理的策略和运行时服务治理策略,其中运行时治理策略,诸如k8s这样的CAAS平台可以提供,这里我们着重讨论一下业务服务治理的话题:
*有关元数据管理平台,之后的文章会有讲解
那么最后我们需要把这些部署到k8s上,那么k8s本身的考量和设计就非常重要了,接下来我们看一下k8s本身:我们需要考量什么东西和作什么样的架构决策。 k8s-运行时服务治理能力说明: K8s-CAAS执行架构(物理拓扑)如下: 以上是简化图,后续有关执行架构的文章会详细说明。 异地多活技术: 有关运维、监控、客户端架构设计、安全方面、异地多活等话题,因为这些话题也是好大好大,所以我会在后续文章讲到。 总结 我们要把控全局,关键因素要心里有数,关键部分逐步验证,分步实施,不仅仅是要有大的架构规划,还要有细到应用框架的设计,保证全栈形成有机整体,而不是脚痛医脚,头痛一头,做到统一化治理,注意成本平衡,相信我们会越做越好! |
|
来自: 昵称32276360 > 《待分类》