精华内容
下载资源
问答
  • 服务器架构

    2014-05-18 22:04:59
    服务器架构图,开发服务器必须要服务器进行合理的架构,前期不准备好,后期修改BUG是很头疼的,这里是本人开发项目时的写的构架图,可以供大家参考。
  • 系统架构服务器架构

    千次阅读 多人点赞 2019-10-09 14:46:46
    服务器架构图多以物理视图呈现,物理视图用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上,用于指导系统的部署实施过程。受众多为运维和实施人员。 其实服务器架构如何...

    前言

    服务器架构图多以物理视图呈现,物理视图用于描述系统软件到物理硬件的映射关系,反映出系统的组件是如何部署到一组可计算机器节点上,用于指导系统的部署实施过程。受众多为运维和实施人员。

    其实服务器架构如何架设完全根据业务场景,数据量或者用户量等因素进行衡量,并没有什么架设方案是一定的,遵循“两利相权取其重”,经过综合考量后,选择最优方案。

    以下根据不同场景进行服务器架构架设进行物理视图展示(以下示例均以物理服务器为节点,不考虑虚拟化分割和容器部署情况)。

    一、单台服务器

    一般在用户量不多,应用使用频率不高,数据量不太大,业务场景相对简单情况下,单台服务器就可以满足使用。也就是一台服务器上只运行应用容器(如tomcat)和数据库,让系统运行起来,用户能通过网络访问即可,单台服务器不存在应用于数据库网络连接问题,因为应用和数据同在一台服务器,完全的"本地"环境;当然应用访问压力和数据负载压力都由一台服务器承担。其实这种完全单台的情况,一般都用于测试环境或者开发环境,再简单的生产环境至少再多一个灾备服务器会显得更优雅。

    二、应用、数据服务器分离

    如果随着用户量的增长和数据量的增大,应用服务器与数据服务器分离是迈出"分布"的第一步。只需要应用服务器新增一个远程调用数据库服务器的连接,有效的缓解了应用服务器负载的压力。当应用服务器和数据服务器需要通过网络连接时,则有可能由于两个服务器之间网络问题导致数据传输上丢包或者出现数据丢失情况。不过随着网络技术的发展及解决方案的丰富,当数据量或应用访问不太大的情况下,这种担忧完全可以忽略。

    三、应用、数据、文件服务器"三剑客"

    随着系统使用,当文件越来越多,对应用服务器的硬盘存储也是一个挑战,让文件集中化管理显得很有必要。应用服务器只管访问的事儿,数据服务器只存储应用数据(数据库数据),而文件服务器对各种静态文件集中管理,同时释放应用服务器存储空间。

    至于文件服务器到底是做成一个FTP协议的"专业"文件服务器,还是只是把文件分服务器存储,依然使用http协议,就看业务需要了,不过对于FTP管理、http管理总结了以下对比,FTP:

    1、完全基于网络,具有网络文件的上传与下载特性。如支持断点续传,不受工作组与IP地址限制等。

    2、拥有完善的用户权限管理系统,比起网络共享来说,可以详细设置每个用户的权限。如只能上传,不能修改或删除等。

    3、安全性高,可以进行数据的加密传输。更好保护个人隐私。

    与网络共享(http)对比:使用上感觉不如网络共享方便,网络共享的文件可以像本地文件一样使用。而FTP必须是下载下来才能使用。

    应用服务器与文件服务器分离优缺点

    优点:由于处于两个服务器,可以做到访问的分流,减少应用服务器压力,正常用户访问和文件下载上传不共享一个服务器带宽,做到分带宽,如果在文件和应用都在一个服务器会存在上传下载时候,其它访问很慢。且分开的话文件统一管理比较整洁。

    缺点:由于处于两个服务器,涉及到跨域访问问题,需要先把网络传输搞定。两个服务器互相通信时,可能存在网络丢包现象,需要特殊处理。

    备注:如果承载多种类型的文件服务器,可以是文档格式,可以是视频,可以是图片,支持各种类型文件,需要开启多种协议,比如:HTTP,FTP,RTSP,RTMP。流媒体协议主要是三种:HTTP、RTSP、RTMP。

    四、应用集群,加入负载均衡

    对一个应用,利用负载均衡器部署到多台服务器上(未对业务进行拆分),优化了访问请求在服务器组之间的分配,消除了服务器之间的负载不平衡,从而提高了系统的反应速度与总体性能,当然负载均衡器也可以调整每台服务器负载的权重。同时负载均衡器也可以也可实现故障转移,当一台服务器崩溃时候,把访问转到另外可用服务器上,提高了系统架构的可靠性。

    在此阶段,可以在同一服务器下实现动静分离,也就是最初版的前后端分离,用nginx管理并启动前端静态文件工程,tomcat管理后端应用和动态数据。同时一个nginx服务也可以对多个tomcat服务,tomcat服务之间存在负载均衡和故障转移。

    负载均衡器的存在提高了架构的扩展性,简化了管理难度。关于负载均衡故障转移有很多内容要讲,多啰嗦几句,负载均衡可大致分为DNS负载均衡,反向代理负载均衡,基于NAT负载均衡,其中反向代理负载均衡使用较广。当然如果单台负载均衡器感觉不够高可用,也可对负载均衡器进行多台部署,做好灾备。

    应用集群加入负载均衡后,需要注意几点问题:①单点登录②使用session+cookie维护用户③当一台服务器或者多台服务器崩溃,所有的请求由原来的均衡分布瞬间集中到一台服务器或少数几台服务器,需要用户请求突然集中化的处理机制,防止服务器集中接收过多请求而瘫痪。

    五、数据库集群,读写分离

    应用服务器负载均衡后,随着流量和数据的增加,数据库服务器遇到瓶颈,需要对数据库实行集群策略,对数据库访问分流。

    实行读写分离同时,可以加入数据库本地缓存策略。如果数据库读写分离,需要注意数据同步问题。

    六、加入搜索引擎

    加入搜索引擎集群后,需要注意索引数据同步问题:实时增量、定时全量等。

    七、加入缓存服务器

    目前最常用的缓存数据库是redis,一般加入缓存服务,除了分担读数据库的访问压力之外,缓存服务还有数据限流、高速队列、事件发布订阅等效果。加入缓存,主要需要注意的两个问题:缓存穿透与缓存雪崩。

    缓存穿透

    缓存只是为了缓解数据库压力而添加的一层保护层,当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用,频繁去访问缓存中没有的数据,那么缓存就失去了存在的意义,瞬间所有请求的压力都落在了数据库上,这样会导致数据库连接异常。

    缓存雪崩

    缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效,大量请求直接访问数据库,数据库压力过大导致系统雪崩。

    对于缓存相关问题解决方案,网上有很多方法,此处不做描述。到了这一步,服务架构还不算分布式架构,只能算高可用架构。

    八、数据库水平拆分、垂直拆分

    比如,商品和用户两个数据库原来处于同一个数据服务器,由于数据量不断增长,把商品和用户两个数据库分别放在两个数据库服务器,这种按业务分割业务数据,其实就是垂直拆分。垂直拆分后,要注意不同服务器之间数据关联与同步问题。

    如果当商品服务器又达到性能瓶颈,需要对服务器继续扩展,把同样的商品数据库的数据按条件分到扩展服务器上,这种就属于水平拆分。

    九、应用服务器垂直拆分

    把应用服务器,按业务进行垂直拆分,A业务服务器只负责A业务,B业务服务器只负责B业务,C业务服务器只负责C业务。并对每个业务服务器做好负载及灾备。

    例如,按业务拆分的3个服务器的对应三个域名:

    urlA.com,urlB.com,urlC.com

    根据不同域名请求访问不同服务器,如果涉及到用户需要查询业务A或业务B,直接在用户服务器里写DAO层查询业务A或业务B数据库表。

    此步需要注意的问题:业务服务器之间调用问题

    十、前后端服务器分离

    当服务器访问量继续加大的时候,可添加专门的用于管理前端工程的服务器,为前后端在一个服务器做访问压力分离。至于前端服务器与后端的应用服务器如何关联,则由实际业务场景判断,本文不做描述。至于更多细节,比如CDN服务器等不做描述。

    十一、微服务

    到此步就不是web应用服务了,应用服务进一步抽离为服务节点,应用服务通过调用服务节点来实现整体系统,不但让系统充分解耦,又可以使服务之间紧密相连。这一步已经属于微服务了,微服务之间的调用和消息是需要注意的重中之重。架构的选择不需要跟随"潮流",不是因为微服务火就要把所有项目都做成微服务,要充分判断用户受众及用户量之后,再做架构的选择。要让技术为业务做服务,用技术去驱动业务,驱动发展,而不是要让业务给技术让路。

    十二、加入数据中心

    到这步,应用层已经架构完毕,为实现数据驱动而加入数据中心,实现数据统一管理。让不断增长的数据价值实际落地。

    展开全文
  • 硬件架构: IBM System X3650平台架构: Windows Server 2003+Apache2.2+Tomcat7.0+MySQL5.1系统环境: 支持PHP+JAVA
  • Java项目架构的演变

    千次阅读 2019-04-26 22:59:56
    但这些架构也不是突然就出现的,而是经过不但演变才出现及流行起来的,本文就给大家来梳理下java项目架构的演变历程。 系统架构演化历程 单体架构   大型网站都是从小型网站发展而来的,网站架构也是一样,是从...


      现在出去找工作如果不会点分布式和微服务相关的内容,都不太好更面试官扯蛋。但这些架构也不是突然就出现的,而是经过不但演变才出现及流行起来的,本文就给大家来梳理下java项目架构的演变历程。

    系统架构演化历程

    单体架构

      大型网站都是从小型网站发展而来的,网站架构也是一样,是从小型网站架构逐步演化而来的,小型网站最开始没有太多人访问,只需要一台服务器就绰绰有余了,这时的架构如下:

    在这里插入图片描述
      应用程序、数据库、文件等所有的资源都在一台服务器上,通常服务器操作系统使用Linux、应用程序使用java或者其他语句,然后部署在Apache或者Nginx上。数据库使用MySQL,使用开源的技术实现,然后部署在一台廉价的服务器上就开始了网站的发展之路。

    应用服务和数据服务分离

      好景不长,随着公司业务的发展,一台服务逐渐满足不了需求,越来越多的用户访问导致性能越来越差,数据存储空间开始不足,这时我们需要将应用和数据分离,分离后开始使用三台服务器:应用服务器、文件服务器、数据库服务器。如图:

    在这里插入图片描述

      应用和数据分离后,不同特性的服务器承担着不同的服务角色,网站的并发处理能力和数据存储空间都得到了很大的改善,支持网站业务进一步发展,但是随着用户逐渐增多,数据库压力越来越大,访问延迟,进而影响整个网站的性能,此时需要进一步优化。

    缓存的使用

      网站访问有个著名的二八定律,即80%的业务集中访问在20%的数据上,如果我们将这一小部分的数据缓存在内存中,能够很好的减少数据库的访问压力,提高整个网站的数据访问速度。

    在这里插入图片描述

      缓存常用的组件可以是Redis,ehcache等

    集群的使用

      缓存解决了数据库访问量比较大的问题,但是并不能解决随着业务增多造成的服务器并发压力大的问题,这时我们需要增加一台应用服务器来分担原来服务器的访问压力和存储压力。如图:

    在这里插入图片描述

      通过负载均衡调度服务器,可将来自用户的访问请求分发到应用服务器中的任何一台服务器中,这样多台服务器就分担了原来一台服务器的压力,我们只需要注意会话的一致性就可以了。

    数据库读写分离

      系统正常运行了一段时间后,虽然加的有缓存,使绝大多数的数据库操作可以不通过数据库就能完成,但是任然有一部分的操作(缓存访问不命中,缓存过期)和全部的写操作需要访问数据库,当用户达到一定规模后,数据库因为负载压力过大还是会成为系统的瓶颈,
      这时主流的数据库都提供的有主从热备份功能,通过配置两台数据库实现主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。可以利用这一功能来实现数据库读写分离。从而改善数据库的负载压力,如图:

    在这里插入图片描述

      mysql的读写分离可以通过自身自带的从主复制实现,Oracle的话可以通过阿里巴巴的mycat组件来实现。

    反向代理和CDN加速

      为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。CDN部署在网络提供商的机房。用户请求到来的时候从距离自己最近的网络提供商机房获取数据,而反向代理则部署在网站的中心机房中,请求带来的时候先去反向代理服务器中查看请求资源,如果有则直接返回。如图:

    在这里插入图片描述

      使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户的访问速度,另一方面也减轻后端服务器的负载压力。

    分布式文件和分布式数据库

      任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后,从一台服务器拆分成两天服务器,但是随着业务的增长后面依然不能满足需求,这时我们需要使用分布式数据库,同时文件系统也一样,需要使用分布式文件系统。
      分布式数据库是数据库拆分的最后的手段,只有在表单数据规模非常庞大的时候才使用,不到不得已时,我们更常用的手段是业务分库,将不同的业务数据部署在不同的物理服务器上。

    在这里插入图片描述

    NoSql和搜索引擎

      随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,这时一些NoSQL(Reids,HBase,mongodb)数据库技术和搜索引擎(Solr,Elasticsearch)的时候就显得很有必要。如下图:

    在这里插入图片描述

      NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持,应用服务器通过一个统一的数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

    业务拆分

      当访问量达到一定规模的时候我们可以通过分而治之的手段将整个系统的业务分成不同的产品线,例如我们将系统的首页,商铺,订单,买家,卖家,支付,订单等拆分成不同的产品线。
      具体到技术实现上,也可以根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署维护,应用之间通过RPC框架(dubbo,webService,httpClient…)建立连接,也可以通过消息队列实现异步分发处理。来构成一个完整的系统,如下图:

    在这里插入图片描述

    分布式服务

      随着业务拆分越来越小,存储系统越来越庞大,应用系统的整体复杂度呈指数级增加,部署维护越来越困难,由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务。

    1. 当服务越来越多时,服务URL配置管理变得非常困难,F5硬件负载均衡器的单点压力也越来越大。
    2. 当进一步发展,服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
    3. 接着,服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
    4. 服务多了,沟通成本也开始上升,调某个服务失败该找谁?服务的参数都有什么约定?
    5. 一个服务有多个业务消费者,如何确保服务质量?
    6. 随着服务的不停升级,总有些意想不到的事发生,比如cache写错了导致内存溢出,故障不可避免,每次核心服务一挂,影响一大片,人心慌慌,如何控制故障的影响面?服务是否可以功能降级?或者资源劣化?

    解决方案:公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。也就是我们将的分布式服务或者微服务。

    微服务的设计原则参考此文:
    https://dpb-bobokaoya-sm.blog.csdn.net/article/details/87305626

    展开全文
  • 服务器架构的演变过程

    千次阅读 2018-09-02 17:06:53
    服务器架构的演变过程 1,传统单一模式 一个项目系统包含所有的功能,如登录,注册,验证,前台展示,后台管理等,所有的功能在一个项目中实现 缺点: 1)不便于维护,系统的每个功能耦合性太高,如果某一个功能出现...

    服务器架构的演变过程

    1,传统单一模式

    一个项目系统包含所有的功能,如登录,注册,验证,前台展示,后台管理等,所有的功能在一个项目中实现  
    

    缺点:
    1)不便于维护,系统的每个功能耦合性太高,如果某一个功能出现bug,整个项目都得下线维护修复,会影响整个功能模块;
    2)横向拓展性不好,特别是目前互联网项目,需求变化很高,代码都不能写死,就是为了便于后面需求变化,增加新功能,而因为每个功能之间耦合性太高就导致修改一处,可能导致需要修改很多处.功能的修改或增加麻烦
    3)因为整个项目放在一个服务器中,存在并发量问题,如果用户多了,并发问题亟待解决.于是变出现了下面的模式–增加集群的方式.
    这里写图片描述


    2 集群模式

      集群模式为了解决访问量大的情况,把项目放到多个服务器上,通过添加服务器的方式来缓解用户访问大的压力.
    这中集群模式在一定程度上能够增加并发量,但也面临问题.
    

    这里写图片描述

    缺点:

    • 1)重复登录问题;这个模式添加集群,就得使用负载均衡服务器(通常使用nginx作为服务器),如果一个用户第一次登录访问被分配到了1号服务器,服务器存储了该用户的信息(session域中),但是用户下次的请求就不一定再被分配到这个服务器了,假如这次被分配到了2号服务器,则该服务中没有该用户的session信息,则会要求该用户重新登录,用户体验不好.

      解决:针对上诉问题,解决方案


      • a,服务器之间session广播,但是广播是要占用网络带宽的,即会占用网络资源,在用户访问已经很大的时候,应该尽可能减少消耗,不然用户登录网站也会缓慢,体验不好等,这时,服务器的集群数量也不能太多,超过一定数量后,session广播消耗的资源的坏处可能比搭建集群带来的好处还大,所以优势会随着集群数量呈现先增长再下降的负向的抛物线趋势.

      • b,可以采用session共享的方式,采用redis缓存服务器作为一个公共的存储用户信息的地方,在用户访问服务器1时,服务器1去redis中会查看是否有登录信息,在访问到服务器2时,服务器2也去redis服务器查看,这样把信息都让redis来管理,效率更高.
        这里写图片描述
    • 2)每个功能之间的耦合度依然很高,不便于新增或维护功能.于是便有了下面的架构模式–分布式

    3 分布式架构

    分布式架构比之传统的单一模式的改变就是 分布式架构把整个系统拆分为各个小的功能模块,每一个又独立成为一个系统,只是这个系统只提供单独的功能,而每个系统又分别放到不同的服务器中,这样形成了一个多个服务器架构的网,每个功能相互协作

    这里写图片描述
    * 优点:
    1)解决了功能耦合度高问题,每个模块相互独立,如果某一个功能需要修复,只需修改这一个就好,不影响整个系统运行.而且如果需要添加新功能,非常容易切入到系统中来,且不改动其他的模块.
    2)真正能够解决并发问题,因为每个功能模块拆分开了,如网站搞促销活动,商品浏览页面展示的访问压力大,可以有针对的添加集群,解决高并发问题,即可实现对每个节点(即每个独立的功能)添加集群.
    * 缺点: 每个模块虽然独立,但是可能每个模块有一些通用的功能,而这些通用的功能在每个功能中都要写一遍,如何提高代码复用性,这是一个问题.于是便有了下面的架构模式


    集群和分布式的区别

    集群:即每个服务器上的提供的功能和服务相同, 只是人多,做的事情却是相同的; 相当于同一个工程代码拷贝多份部署到多台服务器,每台服务器单独独立部署运行。
    分布式: 即每个服务器上功能不同,大家要相互分工, 协作完成整个工程; 把系统按照模块拆分成多个子系统;多个子系统相互协作才能完成业务流程系统之间需要进行通信。

    4 SOA模式–(Service Oriented Architecture)面向服务架构

     soa模式的服务架构,也是分布式架构,只是针对之前出现的问题,做了改进,即为了提高代码的复用性问题,
      将整个系统主要分为2部分,把工程都拆分成服务层工程、表现层工程。
    

    服务层中包含业务逻辑,只需要对外提供服务即可。
    表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。工程都可以独立部署,而表现层又可以细分为各个不同的部分,而这些模块都是对外提供服务,只是具体分工不同,但是他们每个要进行逻辑处理时,可以调用服务层的同一个业务逻辑.这样一个业务逻辑可以供表现层的多个服务调用,代码复用性提高.
    这里写图片描述

    展开全文
  • 结合实例谈项目架构设计

    千次阅读 2018-01-17 16:28:15
    作为一个移动端开发人员来讲,是很难接触到后端项目架构的,所幸,从2015年开始,负责部分管理工作,参与了项目架构相关的工作。项目从小到大,架构也越来越复杂,特别是最近做的一个跨国型项目,涉及到国内国外...

    作为一个移动端开发人员来讲,是很难接触到后端项目架构的,所幸,从2015年开始,负责部分管理工作,参与了项目架构相关的工作。项目从小到大,架构也越来越复杂,特别是最近做的一个跨国型项目,涉及到国内国外服务器的部署,尤为复杂。本文结合这些项目实践,介绍基于阿里云的后端架构设计。(部分内容为引用他人的文章,文中已有说明,咱是尊重版权的)







    1.基础架构:

    2015年初,团队做了一个美食项目,业务逻辑比较简单,主要是实现用户、餐馆、美食三元素的增删改查及三者之间的关联查询。后端程序采用的是php,前端面对的是iOS和Android两款App。当时购买了一台阿里云ECS服务器,在该服务器上安装了MySQL以用于数据存储。应用程序、数据库、文件等所有资源都在一台服务器上,网站架构如下图所示:



    此架构简单,适用于项目初期,访问量比较小情况。这里着重要说一下的是,此项目中涉及到资源文件的存储但并没有用到OSS服务器,我们的做法是在客户端在上传图片文件的时候,接口程序会将图片压缩为所需的多种尺寸,并保存在对应的文件夹下,前端再取图片的时候在URL后拼接对于的尺寸即可访问。如客户端上传了一张图片,程序会压缩为30*30,120*120,240*240三种尺寸,客户端根据界面需要采用xxxxx_30.png的方式访问,这个功能在阿里云的OSS服务器上有现成的服务,无需自己压缩。


    2.应用与数据分离架构:

    2015年底,团队开始做了一个图片社交项目,其功能是全部模仿Instagram,但是内容主要针对的是服装、奢侈品。用户通过手机拍摄一些奢侈品、服装相关的视频、图片,并添加对应的下载链接,发布到平台后,用户可以看到其他所有人发布的内容,并可以根据链接购买。
    这个项目中涉及到大量视频、图片的处理,这里我们实现了应用服务、数据服务、资源服务的分离。我们购买了四台阿里云服务器,分别是两台ECS、一台OSS、一台RDS,其结构如下图:





    3.集群式部署初级架构
    2016年我们开始做一个大型的在线教育平台项目,经历一年的磨合,项目趋于稳定,我们的服务器架构也日臻完善。本想总结一下服务器的架构,在下笔之前在网上看到了他人总结的一篇文章 项目架构设计总结,再此先向作者表示敬意,以下是引用的这篇文章的部分内容:


     --------------------------------------引用有此处开始--------------------------------------



     项目背景
     
    项目的前端主要为ios应用以及一些web管理系统,后端的职能主要为前端提供数据接口。我个人在项目中主要负责整个后端的架构设计、服务器运维、php开发等一系列后端工作,因为主要是我一个人负责,在一定程度上也减少了许多沟通成本。
     
     总体架构
     
     项目后端架构使用阿里云服务搭建,其中RDS为主从集群,并配备灾备实例。ECS可根据业务量动态弹性伸缩,其余服务均采用单实例的方式远程调用。
     



     
     VPC
     
     搭建VPC的原因有以下几点

     1.可以将业务数据库和业务服务器放置在可以自己掌握的同一内网,可以提高一些安全性。
     2.阿里云服务之间通过内网访问的流量是不收费的。所以在选购服务时,带宽可以选择流量版,这样在保证带宽速率的同时,还可以极大的减少运维费用。
     举个例子:同样一台ECS,在同为百兆带宽的情况下,每月的费用如下图:
     
     按固定带宽



     按使用流量
     


     当然,能这样的做的原因也是因为在这个架构中,ECS仅处理业务逻辑,几乎不存储文件资源。大部分静态资源,如视频图片等,都是存储在OSS上。如果存放静态资源,比如下视频或图片什么的,流量一多那就很亏了。
     3.内网访问,稳定而且速度快。
     
     业务数据层
     
     RDS

     项目一开始,RDS选购的是共享型单实例的,随着业务量的提升,可以多区域部署只读实例。另外,保险起见,主实例可以配有一个灾备实例,防止意外发生。
     
     Redis
     提到阿里云的这个Redis,不得不吐槽一句,它竟然是不支持主从的,只能单实例,不过,用它做数据缓存,还真是蛮不错的选择,响应速度非常快。而且,因为是放置在内网的且只能内网访问,所以安全性也很高。
     
     MongoDB
     结构型数据,主要存储档案式的数据,比如每个用户的操作行为,以档案式记录并进行统计分析,方便下一阶段的项目做个性化服务。另外一些关联复杂的数据,也可以用MongoDb存储,可以提高访问速度。还有,一些对软件应用版本比较敏感的数据也可以存在MongoDB中,比如a版本拿到A数据,b版本拿到B数据,而这个AB数据都是由很多关联关系复杂的数据所组成,如果把这些数据根据版本号存储在不同的MongoDB档案中,需要时,直接根据版本号拿就可以了,这样就避免了很多的mysql查询。
     
     静态资源
     
     OSS + CDN

     OSS存储静态资源,CDN(内容分发网络)可以加速静态资源的下载速度。至于资源链接地址,客户端可以通过接口访问从后端业务数据库中拿到。
     服务器安全
     
     运维层面

     1.选购了阿里云的web防火墙和态势感知的服务。这两个服务可以实时监控服务器状态,识别并跟踪攻击来源和类型,可以说,用这两个工具也节省了很多人力成本。阿里云还有其它安全类产品,可以根据项目选购,使用起来也都很方便。
     2.配置firewalld。
     
     业务层面
     针对接口访问的安全性,主要做了以下工作
     1.签名验证:防止伪造请求
     2.访问频次限制:计数器是用phpredis制作的毫秒级计数器
     3.https访问
     4.部分敏感数据,使用RSA非对称加密
     
     服务器集群
     
     主ECS

     通过这台ECS,可以管理其它从属的ECS,并查看状态。安装的主要工具为ansible。
     如果不需要用这台ECS来做负载均衡的话,可以配置白名单连接,只允许管理员ip才能访问。
     
     从属ECS
     这类ECS服务器只存放逻辑代码,所以当需求量增加时,只需增加此类服务器的个数即可。而且,在增加个数时,可以使用之前制作好的镜像,创建多台相同环境的ECS服务器。每台ECS的web环境为nginx1.10和php7,微服务容器环境用的docker。
     
     负载均衡
     负载均衡可以采用两种方式
     1.购买阿里云的负载均衡实例(注意要买带公网ip的)。由该负载均衡实例接收请求后,会分发到内部服务器。
     2.在某台具有外网ip的ECS上使用nginx部署负载均衡服务。
     
     个人更倾向第一种,毕竟管理起来比较方便,节省人力。
     
     使用到的第三方服务
     
     Coding

     后端的所有代码都是放在Coding上的,喜欢Coding的原因有三个。
     1.私有git仓库没有个数限制。
     2.有ios客户端且比较好用。
     3.操作界面好看。
     
     后端代码的自动部署是通过Coding的webhook实现的
     具体操作可以去看这篇博客《利用Coding的webhook自动部署项目》。
     
     实现的场景:代码的自动部署与持续集成。
     当我提交代码到开发分支上时,测试服务器上会自动更新开发分支上的代码。
     当我把开发代码合并到主分支上时,正式服务器会自动拉取master分支上的代码,可谓是方便快捷。
     jenkins 之类的工具虽然也尝试过,但是感觉部署起来很不方便,不够定制化,而且还消耗了一部分服务器资源。
     
     
     后端逻辑层架构
     
     接口

     项目起初的接口是基于phalapi框架开发,现在逐步过渡到基于laravel5.3开发。
     项目起初选择phalapi的原因
     1.phalapi框架是轻量级的接口发框架,开发起来比较便捷、快速,尤其是那个依赖注入挺好用的。
     2.phalapi框架有很多现成的扩展可以使用,不用去找,而且这些也能基本满足业务的需要。我个人还基于这个框架开发了两个扩展,一个是关于使用workman的,一个是关于使用gearman的。
     其中gearman是用来异步处理请求的,详细介绍可以看这篇博客《基于Phalapi框架的gearman扩展(异步并发)》
     根据业务量提高性能
     
     http请求的并发性能可以通过增加ECS实现,针对部分耗时较长且无须即时回调的请求,可以用gearman异步处理。
     数据库的并发连接数可以通过增加配置来提高,也可以通过创建只读实例进行读写分离,提高数据处理能力。再往后,可能需要搭建hadoop管理数据库集群,不过等用上hadoop的时候,应该已经不是项目初期了,至少数据量得是TB级的了。
     其它还可以采用优化nginx配置,优化linux内核,采用高速固态硬盘等等的手段。
     #总结评价
     这套架构基本上可以完全满足项目初期的业务需要,而且所有的云服务费用总和也非常少(相比于自建服务器机房)。随着业务量的提升,可以逐步升级配置以应对需求,还可以在短时间内临时性的提高并发处理能力。总结起来就是省钱、省时、省力气。

     ----------------------------------------引用到此为止--------------------------------------




    4.集群式部署国际化架构


    随着业务的扩展,最近我们的项目需要发布到海外市场,原有的服务器架构已经不能满足市场的需求。由于之前并未接触如此大的项目,对海外市场服务器的部署非常不了解,在跟阿里云架构师沟通的基础上,我们得出两种解决方案:


    方案一:
    阿里云有一款叫全球加速的产品,该产品不用购买和部署海外服务器,只需购买全球加速服务,阿里云接入其自建的全球骨干网络,据说可实现海外访问100ms的延时。不过此种方式,成本较高,我们选择了放弃,其结构如下图:


    方案二:


    第二种方案就是在海外部署服务器,其结构如下图:




    在上一种架构的基础上,在所需要的点购买ECS服务器,海外节点通过香港入口访问国内的RDS和Redis。同时在海外对应的节点部署CDN,用于访问OSS服务器时的加速,海外用户访问对应节点的CDN,CDN通过香港入口访问OSS服务器,并将所访问的对象文件缓存到对应的节点,当用户下次再次访问该对象时,直接从对应的CDN节点缓存中获取,以此方式提高访问速度。

    展开全文
  • 常用web服务器架构理解

    千次阅读 2018-06-24 17:39:16
    一、服务器架构理解 一个Web项目上线,必须依托于服务器成为互联网之中的一个节点,要使我们的应用得以运转,这个节点内容需要进行一系列的工作环境安装配置,而为了目标项目的安全性、稳定性、灵活性,同时考虑...
  • 电商网站项目架构

    千次阅读 2018-09-28 16:00:42
    相关中间件可参考Cobar(阿里,目前已不在维护),TDDL(阿里),Atlas(奇虎360),MyCat(在Cobar基础上,国内很多牛人,号称国内第一开源项目)。 分库分表后序列的问题,JOIN,事务的问题,会在分库分表主题...
  • 大型Java项目架构演进(小白)

    千次阅读 2017-06-10 09:19:47
    增加服务器 大部分的访问都在小部分的数据(缓存)上 增加缓存(具有哪种业务特点的数据适合使用缓存) 远程缓存 远程单机缓存 远程分布式缓存 (集群) 分布式缓存在扩容时会遇到什么问题 分布式缓存的算法有哪...
  • 系统逻辑架构/服务器架构,企业系统大同小异,一般大型企业系统的架构。我每个项目都在此基础上修改,希望对你也有帮助,通过PPT画的。
  • 分布式游戏服务器通用架构的设计

    千次阅读 2019-09-11 23:30:40
    对于游戏服务器架构,不同项目除了游戏玩法、匹配规则大不相同外,其余部分如日志系统、TCP 连接管理,玩家数据存储,数据库连接与访问等大同小异。游戏服务器架构中高并发、可扩展是主要的设计点。本 Chat 将从 0 ...
  • 服务器架构】十张图带你了解大型网站架构

    万次阅读 多人点赞 2017-10-25 19:42:17
    说道大型网站,就的先说大型网站的特点:高并发,大流量,高可用,海量...应用程序、数据库、文件等所有资源都在一台服务器上,通常使用 Linux PHP MySQL Apache 就可以完成整个项目部署,然后再买个域名,租一
  • 收藏:国产服务器和处理器架构

    千次阅读 2020-08-06 00:00:00
    服务器是一种为客户机提供服务的高性能计算机。CPU作为服务器的运算和控制核心,其指令集架构有CISC和RISC两种。从性能角度来说,CISC与RISC并无绝对的孰优孰劣之分。目前看来,C...
  • 今天写一下游戏服务器架构,主要还是还是分析下服务器架构的原理,以及解决的问题 1、服务器架构演变的最主要的原因是 1、解决压力的问题,想用较低的价值组合完成任务,也就是一堆垃圾服务器组成集群完成任务...
  • 后台服务器架构设计要点

    千次阅读 2018-12-22 10:49:08
    想做后台服务器架构设计,要把握以下几个因素 1. 要处理多大的数据量 2. 有多少种的数据 3. 延迟有多高 4. 要不要处理通知 通常情况下,数据种类越多,数据量越大,系统架构越复杂; 比如 处理 百万级的请求 一台...
  • 项目是使用python实现的基于BS架构的FTP服务器程序,该FTP服务器程序使用web方式进行部署与管理,可以直接通过浏览器访问内置的web服务器进行配置与管理FTP服务
  • 阿里云服务器部署架构

    千次阅读 2014-07-29 11:37:15
    最近要上马一个项目,客户要求全部部署到阿里云的服务器,做了一个阿里云的部署方案. 跟传统的部署相比,用云盾替代了传统的防火墙,负载均衡设备也不用自己买了,购买一个LBS负载均衡服务可以添加10个负载均衡实例,内网...
  • wincc冗余服务器的详细配置要点,实际工程项目经验总结
  • 从一个小网站说起,一台服务器也就够了, 文件服务器和数据库都部署在一台机器上,所成All in one 随着用户越来越多,访问量越来越大,硬盘、CPU、内存等开始吃紧,一台服务器已经满足不了了 这时我们讲数据...
  • 因此,游戏服务器端软件的架构,本质上也是游戏服务器这个特定领域的软件架构。 软件架构的分析,可以通过不同的层面入手。比较经典的软件架构描述,包含了以下几种架构: 运行时架构——这种架构关心如何解决...
  • 经典游戏服务器架构概述

    千次阅读 2018-03-07 22:24:33
    因此,游戏服务器端软件的架构,本质上也是游戏服务器这个特定领域的软件架构。软件架构的分析,可以通过不同的层面入手。比较经典的软件架构描述,包含了以下几种架构:运行时架构——这种架构关心如何解决运行效率...
  • 15 个优秀开源的 Spring Boot 学习项目,一网打尽!

    万次阅读 多人点赞 2019-12-12 11:44:43
    Spring Boot 算是目前 Java 领域最火的技术栈了,松哥年初出版的 《Spring Boot + Vue 全栈开发实战》迄今为止已经加印了 8 次...当然就是开源项目了,今天松哥整理了几个优质 Spring Boot 开源项目给大家参考,希望...
  • 华为鲲鹏架构服务器推出好几年了,特别是去年鲲鹏920CPU推出后,更是迎来了一个飞跃,全国装机发货量猛增,在各种应用场景下都发挥了重要的作用。 基于科普的考虑,我前几天发表了一篇文章鲲鹏牛刀小试,演示使用...
  • 7周Spring Cloud微服务架构项目实战

    万人学习 2018-11-05 14:11:01
    本门课程围绕电商项目大觅网的业务场景,基于微服务原则设计电商项目,使用多种诸如Eureka、Feign、...本次课程以实战为基础,让同学们在实战过程中,独立完成网站的架构搭建和项目开发,掌握其中的实现方式与思路。
  • 项目-整体架构

    千次阅读 2018-06-15 08:33:20
    前端架构 用户请求到达网站应用服务器之前的环节 浏览器优化 浏览器本地页面缓存 合并http减少请求次数 页面压缩 CDN 将静态页面分发到离用户最近的...
  • 笔者介绍:姜雪伟,IT公司技术合伙人,IT高级讲师,CSDN...CSDN视频网址:http://edu.csdn.net/lecturer/144 服务器架构技术一直是热点,游戏服务器,各种数据平台系统等等都离不开服务器架构设计,服务器架构设计
  • Android项目架构

    千次阅读 2014-11-05 16:59:11
    另外一点项目架构好比设计模式,个人认为不同的项目适合不同的架构,只有最合适的,没有最好的。 读图分3块 左 中 右 以下按这个顺序解释 ApplicationFramework : 系统提供的基础API ...
  • 单机时间的应用,都很简单,一个应用,一台服务器,就搞定了,大至的架构设计如下图 用户通过Internet访问某个网站,经过DNS服务器解析,找到对应的服务器地址,请求服务器,响应用户请求的信息 优点: 1.部署....
  • 历经过程 阶段一:经历过传统...下一个新的项目的时候,我们又要根据客户的需求重新进行开发,架构稍微好一点的只是开发多少的问题,而不能完完全全地将视频能力输出部分和业务部分很好滴划分; 阶段二:再后来...
  • JavaScript编程入门

    万人学习 2016-12-31 20:27:13
    JavaScript是现在网页开发中使用多的脚本语言,并且随着技术的发展,JavaScript也可以在服务器端进行交互式的代码开发,本课程主要是为刚刚接触JavaScript的读者准备,详细的讲解了JavaScript的基本语法,以及事件的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 362,371
精华内容 144,948
关键字:

服务器项目架构