当双11,双12,618狂欢开始后,每秒订单数成百倍的增加,数以万计的访问量会导致系统的响应速度变慢,不仅仅是电商,越来越多的企业互联网化的过程中系统也面临着高并发的压力。如何去承受如此庞大的并发考验?在业务开发,底层架构上是否可以做到防患于未然?高并发出现时,是否有应急方案?
首先,我们可以先从互联网系统发展中面临的问题来看:
业务开发问题
    比如,一开始做业务的时候可能很随意,一是并不考虑业务模型、系统架构,二是业务之间的耦合比较严重,比如交易和资金业务,有可能资金和外部第三方支付公司的交互状态耦合在交易系统里,这些非常不利于业务的拆分和发展。
底层架构问题
    比如最开始为加快研发速度,会做成单体应用,十几人甚至上百人开发一个大应用,扩展性很差,业务比较难做。开发框架选择五花八门,选用的组件成熟度未经验证,导致上线后出现各种问题。
线上运维问题
    比如运行环境、自动化部署、线上业务运行监控、系统容量的评估等基础支撑建设不到位。面对出现问题的时候,运维无法快速的给出应急的预案,导致线上业务的可用性成为头疼的问题。
这些问题,最终会导致用户体验差,最终流失。
简单,有效的微服务架构是否能够加持“双11”?
微服务架构的本质并不新鲜。分布式系统的理念历史非常悠久。微服务架构也很类似于SOA。它甚至曾经被称为轻量级或细粒度的SOA。确实是这样,思考微服务架构的一种方式就是将其视为没有商用和沉Webservice以及ESB的SOA。尽管这不是一个全新的理念,但微服务架构还是值得讨论的,因为它不同于传统的SOA,更为重要的是它能够解决目前很多组织所遇到的问题。
 
微服务化的过程中,一般会对业务系统进行垂直拆分,比如用户中心、购物车、交易、资金等。在系统拆完了之后要考虑提供什么样的API来满足业务的需求?这里我们要做数据建模+业务建模,数据建模方面包括数据表的设计和扩展支持,数据模型应该非常稳定;业务建模方面,使用标准和灵活的API,而且尽量不用修改代码或者改少量代码就能支持业务需求。最终需要将业务逻辑下沉到服务,Web层专注于展示逻辑和编排,不要涉及过多业务的事情。
 
业务拆分完毕后,需要将各微服务以标准的形式组织起来,在iuap云运维平台中是用Docker将每个服务重新定义,这样运维的可维护性就成为现实。
微服务拆分完毕后,会带来新的问题:原本只需要部署一个单体应用,现在变为了需要部署一堆的微服务,业务上线的过程变的复杂了。每个微服务上线时,又需要进行配置文件的管理,上百个文件,依靠手工的方式进行维护,极易出现问题。这种状况需要自动化部署拆分的微服务,在iuap云运维平台的发布管理中,我们通过做统一的服务编排,以自动化的方式完成线上的部署。
    发布完毕后,所有的中间件及业务微服务,都需要在线管理、自动化管控,并实时监测服务的健康度。当业务压力增大的时候,可以进行微服务实例的秒级扩容。
如何实现性能的持续提升?
    性能的优化,来源于基于数据的量化评估。这个过程也是整个业务迭代过程中,不断循序渐进的过程,通过工具进行科学的调优,避免盲目猜测性能原因。比如运维平台当中,按照服务器维度、系统维度、资源维度、业务维度等指标进行性能的监控。
服务器维度的监控
线上系统维度的监控
    对线上的系统日常访问PV、UV,系统的总体实时流量、负载均衡、请求状态码等指标进行度量,做到对线上的业务运行状况和用户的访问状况了如指掌。
    对线上系统请求总体的响应时间,做全局的监控,当出量流量峰值的时候,如果微服务响应时间变慢,就可以根据资源情况及时的做系统扩容。
资源维度的监控
    以Docker方式组织的微服务,我们会将其放到资源池中统一管理,不同于传统的以机器固定IP为中心的部署方式,像图中这样:
    资源池中的微服务实例数、内存剩余量、CPU可用量、磁盘可用量等信息,都会以图表的方式展示,方便运维及时了解系统状况。
业务维度的监控
    在进行问题深度排查的过程中,微服务之间的调用关系,需要能够以可视化的方式度量,尤其是进行了细粒度的微服务拆分以后。我们采用这样的方式展示系统的调用拓扑:
    对于出现了慢的响应分布,就需要对这些请求进行分析,引起足够的重视,否则这些请求,很有可能会导致整个系统的崩塌。
    对于请求慢的真正原因,运维或开发人员可以随时查看详细的调用栈信息。通过代码的修正与调优,不断消除性能的瓶颈。
从容的进行服务扩容
    通过对系统运行状况的了解,运维人员能够全面掌握业务的运行情况。并且可以到相应的微服务管理页面,进行扩容的操作。就像图中所示的操作方式:
    所以呢,总结一下,iuap云运维平台可以实现服务器统一管控,可视化运维管理;帮助快速构建、加速应用的持续迭代发布;服务自愈、自动弹性伸缩,可谓是应对高并发、高可用的杀手锏!





注意:本文归作者所有,未经作者允许,不得转载