精华内容
下载资源
问答
  • 采用Serverless架构搭建Web应用

    千次阅读 2017-08-04 16:38:14
     在传统Web应用中,服务器是系统不可缺少的组成部分。尽管有时候服务器的前面还有负载均衡器或者专用Web服务器,但完成大部分工作的还是应用服务器。它完成一个应用所有的必要功能,包括存储用户

    本文会向你介绍一种新的可能,一种无服务器的方案来搭建Web应用。使用这个方案大部分运维方面的问题就不需要你自己操心了,而且也省去运行服务器的费用。本文从无服务的优势与限制两方面带您初识Serverless设计。

      在传统Web应用中,服务器是系统不可缺少的组成部分。尽管有时候服务器的前面还有负载均衡器或者专用Web服务器,但完成大部分工作的还是应用服务器。它完成一个应用所有的必要功能,包括存储用户数据、进行安全认证、控制流程等。应用的页面大部分仅仅只是为后端提供界面而已,尽管也会涉及一些控制导航的功能。使用这种许多人称之为多层架构的传统方式,系统一般会由浏览器、应用服务器和多个后端服务构成(见下图)。
          图片描述
      使用Serverless(无服)的方式,可以移除所有这些层次架构,达到更直接的实现。与其仅仅把网页客户端当作应用服务器的界面展示,不如构建一个单页Web应用在浏览器中实现应用逻辑。这意味着你只需要一个简单的静态网页服务器,所有的交互都只不过是应用内容的传输而已,浏览器就像是一个应用容器。这样,最终的设计就是移除传统Web应用架构中所有的中间层次,允许浏览器直接连接到它所需要的服务上。
      使用Facebook、Google和Twitter之类的OAuth 2.0身份认证服务商提供的服务,无须保存用户密码就可以创建用户身份。如果要存储数据,你可以在浏览器端直接使用Amazon DynamoDB之类的服务。在浏览器中无法执行的函数都可以使用Amazon Lambda微服务或者其他专门的Web服务来处理。除了能够简化架构,这种切换到Web服务作为后端的方式,还能让应用获得这些服务与生俱来的可用性和可扩展性优势。
      你可能会好奇到底发生了什么,使这种方式成为可能。为什么现在在一个Web应用中,中间层的应用服务器变得可有可无呢?答案是,自从2015年以来,类似Amazon这样的云服务提供商开始对外提供服务的API,这使得无服务器的方式成为可能,Amazon本身也为如何使用他们的工具和基础设施提供了最好的示范。
      基于Web标准搭建一个单页Web应用,而不是使用服务器端Web框架来完成,我们可以快速应用一些新兴技术。例如,我们不再需要将应用的数据模型绑定到任何一个对象层级或者数据同步机制上,因而能更方便地集成不同服务。既然我们所有的工作都倚赖于Web,就不必拘泥于以前搭建Web应用的成见,可以用目前最新的技术来搭建应用(见下图)。
       图片描述

    无服设计的好处

      如果你在寻找一种快速搭建低成本Web应用的方法,无服Web应用很可能就是一个解决方案。不需要花费时间和精力了解传统Web应用技术栈的各个层级,采用这种方式你能更专注于实现业务功能,有人会为你操心运行维护和可扩展性的问题。接下来让我们深入探讨无服设计的好处,帮助你在考虑下一个项目中是否使用这种方式时做出更明智的决定。

    1. 零服务器

      无服设计最明显的好处就是不需要维护服务器(不管是物理的还是虚拟的)。你不需要担心打安全补丁、监控CPU和内存使用情况、回滚日志、磁盘空间不足或者其他在维护自有服务器时经常碰到的运维问题。和大多数平台即服务(PaaS)方式一样,无服设计能让你专注于应用开发,而无须担心基础设施的问题。

    2. 易扩展

      这种设计方式的另一大好处是,你可以依靠云服务供应商来扩展自己的应用。在做水平扩容时,不需要忙不颠地在几个负载均衡应用服务器之间保持数据的一致性,你可以直接连接Web服务,而它们已经解决了数据一致性的问题。这意味着不管你的应用有几个用户、几百个用户,还是几十万个用户,只需要修改Amazon Web Services控制台的一些设置就可以保证完美的运行。

    3. 高可用

      另外,使用这种设计能轻松实现高可用性。你不必为了升级而关闭应用服务器,或者为了实现“热”部署而扩建基础设施。不再会有服务的重启或者部署包在服务器间的拷贝。最妙的是,Amazon有一群训练有素的员工7×24小时守护着你的基础设施,一旦发现问题随时能够响应。

    4. 低成本

      这些服务的成本可以非常低。使用无服的方式以及利用Amazon的免费套餐(Free Tier),一个月支付几美分就可以运行你的应用。一旦超过了免费额度,其费用经常也是随着你的用户量线性增长的(考虑费用最高的情况)。我们在这本书里构建的应用就算扩展到100万的用户,一天也只需要花费一杯咖啡的钱。

    5. (微)服务友好

      这种方式可以轻松适应微服务或者其他的面向服务架构。你可以在系统中引入特定的服务以实现自定义身份认证、验证或者异步数据处理。如果有必要,你甚至可以重新引入应用服务器,渐进式地重构应用。反之,如果一开始就使用一个中间层来控制所有的安全证书,就很难切换到需要认证的Web服务上。这些应用服务器没办法像无服应用一样,在应用层管理身份信息。

    6. 代码更少

      在传统Web应用里,一些操作(比如导航)在Web客户端和服务器端都需要执行,造成了代码的重复。有时候,这种重复工作并不明显,尤其当服务器代码是用不同的语言写时。而在无服应用中,应用逻辑都移到了客户端,很容易保证应用内不再有重复的代码。将应用逻辑代码放在一个位置(以及用一种语言实现)帮助我们解决了这个问题。
      此外,无服的方式更便于构建和排错,因为系统的组成部分变得更少了。Web应用天生就是分布式的,也就是说,正如CAP理论所述 ,它们在同一个网络的节点间传递消息(一般是以请求和响应的形式),限制它们的是实现方式。
      有些应用会比其他应用更分散(more distributed)。一个系统越分散,就越难排错。移除应用中的中间层能减少其分散的程度。在我们这个简单的应用中,如果一个客户端需要从一个数据库中获取数据,就会直接连接数据库,而不是通过中间层连接。这就意味着系统中的网络节点更少,也意味着如果出现问题,需要定位的地方更少。
      如上所述,构建一个无服应用的理由有很多。学完本书,你就会明白为什么这种方式如此强大。了解了无服应用的这些优点,我们再来看看它有哪些限制。

    无服设计的限制

      尽管无服架构有许多优点,但它也不是适用于所有类型的应用。为了享受这种设计带来的益处,你必须接受一系列的限制。如果你的应用不能适应这些限制,那么它很可能不是最合适的构建方式。所以在搭建应用之前,让我们一起看看这些限制。

    1. 供应商锁定

      首先最大的限制就是你使用的Web服务必须支持第三方身份认证服务商,这样在云服务提供商的选择上就受到了限制。所以如果使用无服的方式,你就会依赖于第三方服务,供应商锁定也就成了一个问题。构建一个基于其他公司服务的系统,意味着这个应用的命运和供应商公司的命运绑在了一起。如果供应商公司被收购、破产或者改变商业模式,你的应用不下大力气修改就很难在其他地方运行。所以,评估服务提供商的业务目标和长期稳定性与技术选型是同样重要的。

    2. 奇怪的日志

      所有运维关注的事情,比如应用日志,在你使用无服设计之后会呈现新的形态。当你把所有请求都通过一台服务器路由时,记录下所有信息以查看用户正在做什么是非常简单的事情。没有了这种中心化设计,日志的记录必须由每个支撑应用的不同Web服务来实现。这些日志格式跟大部分应用服务器日志都不同,记录的数据也很可能是你不熟悉的。

    3. 不一样的安全模型

      对于无服应用,有些常见的安全隐患不复存在,但你将会遇到一些不熟悉的新问题。比如,为了安全而验证用户数据,结果不能在浏览器中安全地实现。你需要假设有些恶意用户可能会在浏览器中劫持证书而使用该证书授权的Web服务。使用无服的方式,意味着你不能把浏览器中的应用验证逻辑和安全验证逻辑放在一起,必须分开实现。
      Amazon提供的许多Web服务都能验证请求。然而,对于有些应用来说,很难只用Web服务提供的工具来实现充分的有效性约束。比如,在浏览器中直接编写文本时,你不可能放心地将写入的数据编码后存到数据库中,保证不会有跨站脚本攻击发生。因为攻击者不使用应用就能直接将这个数据添加到数据库。
      这种情况下,你有(至少)两个选择。第一,可以假设某些用户可编辑的表可能包含未经验证的数据,然后针对性地设计系统的其他部分。比如,用户只能写入他们自己可读取的数据,这是可行的方式。第二,可以将某些写操作委托给自定义Web服务,比如可以使用Lambda函数来进行验证,并且以一种安全的方式写入数据。我们将会在第6章的“使用Lambda构建微服务”中详细介绍。

    4. 不一样的身份模型

      外部身份管理是我们这本书构建的应用中的一个独特功能。使用Web服务来管理身份信息有很多好处,但对你来说这种机制可能有点陌生。与将用户信息和其他数据保存在一起的传统方式不同,这些用户资料会保存在一个独立访问的数据存储服务中。如果使用这种方式构建无服应用,一些在数据库中处理用户数据的方法(比如用一个ID关联一张User表)就没办法实现。

    5. 失去控制

      此外,将所有请求路由到统一的中间层可以实现某种程度的控制,这在某些情况下是非常有用的。比如,拒绝访问攻击和其他一些攻击有时候可以在应用服务器上进行阻截。对你而言,放弃对身份认证的直接控制可能想一想都觉得可怕。我们后面在第7章会用一整章来专门探讨这些安全问题。

    6. 规模与成本的关系

      最后,你需要了解这些服务的开销。虽然能够自动扩展应用这一点非常厉害,但易于扩展同时也意味着花钱更容易。你需要了解这些服务的定价策略以及当用户增加时这些价格的变化。
      既然你已经了解了无服Web应用的代价,我们可以开启这本教程,探索一下无服Web应用是如何实现的。在教程中,你可能会发现这种设计方式为你开发的Web应用带来的其他好处和限制。一旦知晓了无服应用的全貌,就可以判断下一个项目是否适合这种方式了。
      本文选自《Serverless架构:无服务器单页应用开发》,点此链接可在博文视点官网查看此书。
                   图片描述
    想及时获得更多精彩文章,可在微信中搜索“博文视点”或者扫描下方二维码并关注。
                       图片描述

    展开全文
  • 本课程是一门具有很强实践性质的“项目实战”课程,即“企业台系统实战”,其中主要包含三大块核心内容,如下图所示(右键可以在新标签页打开图片放大查看): 即主要包含以下三大块内容: ① 企业内部应用系统...
  • 这些技术的出现给电子商务时代的WEB应用程序的开发提供了一个非常有竞争力的选择。怎样把这些技术组合起来形成一个适应项目需要的稳定架构是项目开发过程一个非常重要的步骤。完成这个步骤可以形成一个主要里程碑...

    1. 架构概述

    J2EE体系包括java server pages(JSP) ,java SERVLET, enterprise bean,WEB service等技术。这些技术的出现给电子商务时代的WEB应用程序的开发提供了一个非常有竞争力的选择。怎样把这些技术组合起来形成一个适应项目需要的稳定架构是项目开发过程中一个非常重要的步骤。完成这个步骤可以形成一个主要里程碑基线。形成这个基线有很多好处:

    各种因数初步确定

    为了形成架构基线,架构设计师要对平台(体系)中的技术进行筛选,各种利弊的权衡。往往架构设计师在这个过程中要阅读大量的技术资料,听取项目组成员的建议,考虑领域专家的需求,考虑赞助商成本(包括开发成本和运行维护成本)限额。一旦架构设计经过评审,这些因数初步地就有了在整个项目过程中的对项目起多大作用的定位。

    定向技术培训

    一旦架构师设计的架构得到了批准形成了基线,项目开发和运行所采用的技术基本确定下来了。众多的项目经理都会对预备项目组成员的技术功底感到担心;他们需要培训部门提供培训,但就架构师面对的技术海洋,项目经理根本就提不出明确的技术培训需求。怎不能够对体系中所有技术都进行培训吧!有了架构里程碑基线,项目经理能确定这个项目开发会采用什么技术,这是提出培训需求应该是最精确的。不过在实际项目开发中,技术培训可以在基线确定之前与架构设计并发进行。

    角色分工

    有了一个好的架构蓝图,我们就能准确划分工作。如网页设计,JSP 标签处理类设计,SERVLET 设计,session bean设计,还有各种实现。这些任务在架构蓝图上都可以清晰地标出位置,使得项目组成员能很好地定位自己的任务。一个好的架构蓝图同时也能规范化任务,能很好地把任务划分为几类,在同一类中的任务的工作量和性质相同或相似。这样工作量估计起来有一个非常好的基础。

    运行维护

    前面说过各个任务在架构图上都有比较好的定位。任何人能借助它很快地熟悉整个项目的运行情况,错误出现时能比较快速地定位错误点。另外,有了清晰的架构图,项目版本管理也有很好的版本树躯干。

    扩展性

    架构犹如一颗参天大树的躯干,只要躯干根系牢,树干粗,长一些旁支,加一些树叶轻而易举无疑。同样,有一个稳定的经得起考验的架构,增加一两个业务组件是非常快速和容易的。

    大家都知道这些好处,一心想形成一个这样的J2EE应用程序架构(就像在windows平台中的MFC)。在这个路程中经历了两个大的阶段:

    1.1. 模型1

    模型1其实不是一个什么稳定架构,甚至谈不上形成了架构。模型1的基础是JSP文件。它从HTTP的请求中提取参数,调用相应的业务逻辑,处理HTTP会话,最后生成HTTP文档。一系列这样的JSP文件形成一个完整的模型1应用,当然可能会有其他辅助类或文件。早期的ASP 和 PHP 技术就属于这个情况。

    总的看来,这个模型的好处是简单,但是它把业务逻辑和表现混在一块,对大应用来说,这个缺点是令人容忍不了的。

    1.2. 模型2

    在经过一番实践,并广泛借鉴和总结经验教训之后,J2EE应用程序终于迎来了MVC(模型-视图-控制)模式。MVC模式并不是J2EE行业人士标新立异的,所以前面我谈到广发借鉴。MVC的核心就是做到三层甚至多层的松散耦合。这对基于组件的,所覆盖的技术不断膨胀的J2EE体系来说真是福音和救星。

    它在浏览器(本文对客户代理都称浏览器)和JSP或SERVLET之间插入一个控制组件。这个控制组件集中了处理浏览器发过来的HTTP请求的分发逻辑,也就是说,它会根据HTTP请求的URL,输入参数,和目前应用的内部状态,把请求分发给相应的WEB 层的JSP 或SERVLET。另外它也负责选择下一个视图(在J2EE中,JSP,SERVLET会生成回给浏览器的html从而形成视图)。集中的控制组件也有利于安全验证,日志纪录,有时也封装请求数据给下面的WEB tier层。这一套逻辑的实现形成了一个像MFC的应用框架,位置如图:


     

    1.3. 多层应用

    下图为J2EE体系中典型的多层应用模型。

    Client tier客户层

    一般为浏览器或其他应用。客户层普遍地支持HTTP协议,也称客户代理。

    WEB tier WEB应用层

    在J2EE中,这一层由WEB 容器运行,它包括JSP, SERVLET等WEB部件。

    EJB tier 企业组件层

    企业组件层由EJB容器运行,支持EJB, JMS, JTA 等服务和技术。

    EIS tier 企业信息系统层

    企业信息系统包含企业内传统信息系统如财务,CRM等,特点是有数据库系统的支持。


    应用框架目前主要集中在WEB层,旨在规范这一层软件的开发。其实企业组件层也可以实现这个模型,但目前主要以设计模式的形式存在。而且有些框架可以扩充,有了企业组件层组件的参与,框架会显得更紧凑,更自然,效率会更高。

    2. 候选方案

    目前,实现模型2的框架也在不断的涌现,下面列出比较有名的框架。

    2.1. Apache Struts

    Struts是一个免费的开源的WEB层的应用框架,apache软件基金致力于struts的开发。Struts具是高可配置的性,和有一个不断增长的特性列表。一个前端控制组件,一系列动作类,动作映射,处理XML的实用工具类,服务器端java bean 的自动填充,支持验证的WEB 表单,国际化支持,生成HTML,实现表现逻辑和模版组成了struts的灵魂。

    2.1.1. Struts和MVC

    模型2的目的和MVC的目的是一样的,所以模型2基本可以和MVC等同起来。下图体现了Struts的运作机理:



     

    2.1.1.1. 控制

    如图所示,它的主要部件是一个通用的控制组件。这个控制组件提供了处理所有发送到Struts 的HTTP请求的入口点。它截取和分发这些请求到相应的动作类(这些动作类都是Action类的子类)。另外控制组件也负责用相应的请求参数填充 From bean,并传给动作类。动作类实现核心商业逻辑,它可以通过访问java bean 或调用EJB。最后动作类把控制权传给后续的JSP 文件,后者生成视图。所有这些控制逻辑利用一个叫struts-config.xml文件来配置。

    2.1.1.2. 模型

    模型以一个或几个java bean的形式存在。这些bean分为三种:

    Form beans(表单Beans)

    它保存了HTTP post请求传来的数据,在Struts里,所有的Form beans都是 ActionFrom 类的子类。

    业务逻辑beans

    专门用来处理业务逻辑。

    系统状态beans

    它保存了跨越多个HTTP 请求的单个客户的会话信息,还有系统状态。

    2.1.1.3. 视图

    控制组件续传HTTP请求给实现了视图的JSP文件。JSP能访问beans 并生成结果文档反馈到客户。Struts提供JSP 标签库: Html,Bean,Logic,Template等来达到这个目的,并有利于分开表现逻辑和程序逻辑。

    2.1.2. Struts的细节分析

    2.1.2.1. 视图-控制-模型

    用户发出一个*.do的HTTP请求,控制组件接收到这个请求后,查找针对这个请求的动作映射,再检查是否曾创建过相应的动作对象(action实例),如果没有则调用actionmapping生成一个动作对象,控制组件会保存这个动作对象供以后使用。接着调用actionmapping的方法得到actionForm对象。之后把actionForm作为参数传给动作对象的perform方法,这个方法结束之后会返回给控制组件一个 actionforward对象。控制组件接着从这个对象中获取下一个视图的路径和重定向属性。如果为重定向则调用HTTPSERVLETREPONSE的方法来显示下一个视图,否则相继调用requestdispatcher, SERVLETcontext的方法续传HTTP请求到下一个视图。

    当动作对象运行perform方法时,可能出现错误信息。动作对象可以保存这些错误信息到一个error对象中,接着调用自身的saveerrors方法把这个错误保存到request对象的属性中。接着动作对象调用actionmapping对象的getInput方法从动作映射中获取input参数,也就是产生输入的视图,并以这个input为参数生成一个actionforward对象返回。这个input参数的JSP中一般有HTTP:errors定制标签读取这些错误信息并显示在页面上。



     

    2.1.2.2. 模型到视图

    模型到视图指视图在显示之前装载系统数据到视图的过程。系统数据一般为模型内java bean的信息。示意图表现了由控制组件forward过来的有html:form定制标签的JSP 的处理逻辑。

    html:form定制标签处理对象从application scope(通过查询SERVLETCONTEXT对象的属性来实现)获取先前由控制组件actionSERVLET放在那里的动作映射等对象,由html:form 的action属性查得actionform名字、类型和范围等信息,在相应的范围内查找actionform,如果有则利用它的信息填充html form表单[实际填充动作在嵌套的html:text等定制标签的处理对象中]。否则在相应范围内创建一个actionform 对象。

    展开全文
  • web架构的演进了解微服务的概念,进而对微服务的组件有一定的了解; 从而知道为什么需要这些组件,以及这些组件设计的初衷,了解组件的责任和边界 单体架构 最早的时候,带宽所限,一个tomcat就可以搞定一...

    从web层架构的演进了解微服务的概念,进而对微服务的组件有一定的了解;

    从而知道为什么需要这些组件,以及这些组件设计的初衷,了解组件的责任和边界

     

    单体架构

    最早的时候,带宽所限,一个tomcat就可以搞定一个网站或者项目;MVC架构非常流行

    即使在现在一些简单的网站和项目也可以使用nginx + tomcat;因为这样开发和维护成本比较低;

     单体架构--面临的挑战

    维护和 升级 困难

            代码不断膨胀、功能越来越复杂、代码修改牵一发而动全身

    系统可靠性变差

           访问量增加、软件和硬件都面临挑战、雪崩效应

    团队协作效率变差

           重复代码增多,重复造轮子、测试变的复杂

    • 复杂应用的开发维护成本变高、部署效率变

     

    集中式架构SOA

    SOA架构一度也非常流行,能解决我们在单体架构中存在的问题。可以看到企业总线类似于服务网关的作用。

    特点

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

    2、各各项目(系统)与服务之间采用webservicerpc等方式进行通信。

    3ESB企业服务总线作为项目与服务之间通信的桥梁

    优点:

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

    2、可以针对不同服务的特点制定集群及优化方案。

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

    缺点:

    1、系统与服务的界限模糊,不利于开发及维护。

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

    3、抽取的服务的粒度过大,系统与服务之间耦合性高

     

     集中式架构SOA-面临的挑战

    SOA架构解决了应用服务化的问题、随着服务化的越来越深入、服务规模越来越大、服务治理面临的挑战也越来越多

    • 服务框架如何支持线性扩展
    • 分布式框架下的服务调用性能
    •  如何查看日志,快速定位和解决故障      
    • 服务限流、重试、超时控制、服务失败策略
    • 如何实现分布式服务监控
    以上问题都期待我们有一个架构可以解决它,微服务架构风格应运而生。
     

    微服务架构

    微服务架构的特点

    微服务架构实现阿里Dubbo

    注册中心(registry):生产者在此注册并发布内容,消费者在此订阅并接收发布的内容。

    消费者(consumer):客户端,从注册中心获取到方法,可以调用生产者中的方法。

    生产者(provider):服务端,生产内容,生产前需要依赖容器(先启动容器)。

    容器(container):生产者在启动执行的时候,必须依赖容器才能正常启动(默认依赖的是spring容器      

    监控中心(monitor):dubbo提供的一个jar工程。主要功能是监控服务端和消费端的使用数据。

    :服务端是什么,有多少接口,多少方法,调用次数,压力信息等,客户端有多少,调用过哪些服务端,调用了多少次等。

    微服务架构实现SpringCloud 

    基本步骤

    1、启动服务将服务注册到注册中心     

    2、启动服务网关注册到注册中心

    3、服务之间的调用使用一般用feign

    4、外部的流量通过服务网关负载均衡


    还有淘宝的HSF和亚马逊的Coral Service、华为在电信行业的DSF等等

    微服务功能特性

    微服务化的优势 ---- 拥抱变化
      单一职责

           单一职责,这样能聚焦一个指定的业务功能或业务需求。

           开发简单、开发效率提高,一个服务可能就是专一的只干一件事。

           微服务能够被小团队单独开发,利于敏捷交付

    服务 自治

            一个服务就是一个独立的实体

            微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的

            微服务允许你利用融合最新技术和不同的言语(要考虑维护和规范)


    微服务化的挑战----管理复杂度

      服务 的拆分和定义是一项 挑战

            康威定律

    分布式 系统带来的各种复杂性

           运维以及监控 服务升级、版本控制; 

           超大型分布式系统需要考虑性能问题和更复杂的存储、监控和运维等

     

     

    l MVC 架构 业务规模很小时,将所有功能都部署在同一个进程中,通过双机或者前置负载均衡器实现负载分流

     

    l SOA 架构: 随着业务发展,服务数量越来越多,服务生命周期管控和运行态的治理成为瓶颈,此时用于提升服务质量的 SOA 服务治理是关键

     

    l 微服务架构: 随着敏捷开发,持续交付, DevOps 理论的发展和实践,以及基于 Docker 等轻量级容器部署应用和服务的成熟,微服务架构开发流行,逐渐成为应用架构的未来演进方向。
     
     

    个人寄语

    技术是为了解决问题而存在的。

    架构不是一成不变的,不是说定义了单体架构,SOA架构,就一直是这样;

    架构是为了解决问题而慢慢演变的一个过程。其实还有RPC框架;有环境的因素和实际需求共同推动。

    架构是一个逐步演变的过程,soa架构也可能发展出注册中心;

    就比如esb企业总线和服务网关的概念去趋同的;

    比如我2014-2016在项目中的架构使用MQ、可以算是伪分布式架构。

    但是从整体上它并不是微服务架构,从架构层面上它不满足当前互联网项目发展的需要;

    从个体层面上。esb毕竟不是为服务网关设计出来的,

    他有他的历史任务,所以已当前的眼光来看,它是落后的;以当时的眼光来看来看他是一个合适

    的解决方案,是满足当时所需的是优秀的

     

    所以重申一下个人观点,技术是为了解决问题而存在的,我们不能说什么技术流行就用什么技术;

    我们应该看来这个技术解决了什么问题,然后看看它是否能解决我们的问题;

     
     
     

     

     
    展开全文
  • Web基础(三)Python Web

    千次阅读 多人点赞 2018-11-14 19:11:49
    文章目录Python Web基础1. WSGI1.1 概述1.2 实现原理1、WSGI Server/gateway2、WSGI Application3、WSGI MiddleWare1.3 测试 WSGI服务器代码简析1.4 实现WSGI服务器1.5 生产环境Web服务器[Gunicorn]...

    Python Web基础

    在这里插入图片描述

    Web应用的本质:
    1. 浏览器发送一个HTTP请求
    2. 服务器收到请求,生成一个HTML文档
    3. 服务器把HTML文档作为HTTP响应的Body发送给浏览器
    4. 浏览器收到HTTP响应,从HTTP Body取出HTML文档并显示

    所以,最简单的Web应用就是先把HTML用文件保存好,用一个现成的HTTP服务器软件,接收用户请求,从文件中读取HTML,返回。我们上两篇博客已经详细讲解并实现了这样的HTTP服务器zjhttp,除此外Apache、Nginx、Lighttpd等这些常见的静态服务器就是干这件事情的。

    如果要动态生成HTML,就需要把上述步骤自己来实现。不过,接受HTTP请求、解析HTTP请求、发送HTTP响应都是苦力活,如果我们自己来写这些底层代码,还没开始写动态HTML呢,就得花个把月去读HTTP规范。正确的做法是底层代码由专门的服务器软件实现,我们用Python专注于生成HTML文档。

    1. WSGI

    Web服务器网关接口(Python Web Server Gateway Interface,缩写为WSGI)是为Python语言定义的Web服务器和Web应用程序或框架之间的一种简单而通用的接口。自从WSGI被开发出来以后,许多其它语言中也出现了类似接口。

    以前,如何选择合适的Web应用程序框架成为困扰Python初学者的一个问题,这是因为,一般而言,Web应用框架的选择将限制可用的Web服务器的选择,反之亦然。那时的Python应用程序通常是为CGI,FastCGI,mod_python中的一个而设计,甚至是为特定Web服务器的自定义的API接口而设计的。

    WSGI(有时发音作’wiz-gee’)是作为Web服务器与Web应用程序或应用框架之间的一种低级别的接口,以提升可移植Web应用开发的共同点。WSGI是基于现存的CGI标准而设计的。WSGI没有官方的实现, 因为WSGI更像一个协议。只要遵照这些协议,WSGI应用(Application)都可以在任何服务器(Server)上运行, 反之亦然。WSGI就是Python的CGI包装,相对于Fastcgi是PHP的CGI包装

    1.1 概述

    WSGI区分为两个部分
    1. 为“服务器”或“网关”。它用于接收、整理客户端发送的请求
    2. 为“应用程序”或“应用框架”。处理服务器程序传递过来的请求

    在这里插入图片描述

    如上图,Web服务器即第一部分,接收、整理客户端发送的请求,咱们前两篇博客使用C语言实现的zjhttp就是属于Web服务器部分;Web框架即为第二部分,即所谓的Web应用程序。开发Web应用程序的时候,通常会把常用的功能封装起来,成为各种框架,比如Flask,Django,Tornado(使用某框架进行web开发,相当于开发服务端的应用程序,处理后台逻辑)。但是,服务器程序和应用程序互相配合才能给用户提供服务,而不同应用程序(不同框架)会有不同的函数、功能。 此时,我们就需要一个标准,让服务器程序和应用程序都支持这个标准,那么,二者就能很好的配合了,这个标准就是 WSGI

    在处理一个WSGI请求时,服务器会为应用程序提供环境信息及一个回调函数(Callback Function)。当应用程序完成处理请求后,透过前述的回调函数,将结果回传给服务器。

    所谓的 WSGI 中间件同时实现了API的两方,因此可以在WSGI服务器和WSGI应用之间起调解作用。从Web服务器的角度来说,中间件扮演应用程序,而从应用程序的角度来说,中间件扮演服务器。“中间件”组件可以执行以下功能:
    1. 重写环境变量后,根据目标URL,将请求消息路由到不同的应用对象。
    2. 允许在一个进程中同时运行多个应用程序或应用框架。
    3. 负载均衡和远程处理,通过在网络上转发请求和响应消息。
    4. 进行内容后处理,例如应用XSLT样式表。

    1.2 实现原理

    WSGI 将 Web 组件分为三类

    • web服务器
    • web中间件
    • web应用程序

    wsgi基本处理模式为:
    WSGI Server -> WSGI Middleware -> WSGI Application

    1、WSGI Server/gateway

    wsgi server可以理解为一个符合wsgi规范的web server,接收request请求,封装一系列环境变量,按照wsgi规范调用注册的wsgi app,最后将response返回给客户端。以python自带的wsgiref为例,wsgiref是按照wsgi规范实现的一个简单wsgi server。它的代码不复杂。

    在这里插入图片描述

    1. 服务器创建socket,监听端口,等待客户端连接。
    2. 当有请求来时,服务器解析客户端信息放到环境变量environ中,并调用绑定的handler来处理请求。
    3. handler解析这个http请求,将请求信息例如method,path等放到environ中。
    4. wsgi handler再将一些服务器端信息也放到environ中,最后服务器信息,客户端信息,本次请求信息全部都保存到了环境变量environ中。
    5. wsgi handler 调用注册的wsgi app,并将environ和回调函数传给wsgi app
    6. wsgi app 将reponse header/status/body 回传给wsgi handler
    7. 最终handler还是通过socket将response信息塞回给客户端。

    2、WSGI Application

    wsgi application就是一个普通的callable对象,当有请求到来时,wsgi server会调用这个wsgi app。这个对象接收两个参数,通常为environ,start_response。environ就像前面介绍的,可以理解为环境变量,跟一次请求相关的所有信息都保存在了这个环境变量中,包括服务器信息,客户端信息,请求信息。start_response是一个callback函数,wsgi application通过调用start_response,将response headers/status 返回给wsgi server。此外这个wsgi app会return 一个iterator对象 ,这个iterator就是response body。这么空讲感觉很虚,对着下面这个简单的例子看就明白很多了。

    3、WSGI MiddleWare

    有些功能可能介于服务器程序和应用程序之间,例如,服务器拿到了客户端请求的URL, 不同的URL需要交由不同的函数处理,这个功能叫做 URL Routing,这个功能就可以放在二者中间实现,这个中间层就是 middleware。middleware对服务器程序和应用是透明的,也就是说,服务器程序以为它就是应用程序,而应用程序以为它就是服务器。这就告诉我们,middleware需要把自己伪装成一个服务器,接受应用程序,调用它,同时middleware还需要把自己伪装成一个应用程序,传给服务器程序。

    论是服务器程序、middleware 还是应用程序,都在服务端,为客户端提供服务,之所以把他们抽象成不同层,就是为了控制复杂度,使得每一次都不太复杂,各司其职。

    1.3 测试 WSGI服务器

    原理说得太多未免过于抽象,现在使用Python内置的纯Python代码编写的wsgiref服务器来体验一把WSGI服务器是如何工作的

    • 编写hello.py 作为一个Web应用程序

      def application(environ, start_response):
          start_response('200 OK', [('Content-Type', 'text/html')])
          return [b'<h1>Hello, World!</h1>']
      
    • 编写server.py作为一个WSGI服务器

      from wsgiref.simple_server import make_server
      # 导入编写的application函数
      from hello import application
      
      # 创建一个服务器,IP地址为空,端口是8000,传入函数application
      httpd = make_server('', 8000, application)
      print('Serving HTTP on port 8000...')
      # 开始监听HTTP请求:
      httpd.serve_forever()
      
    • 启动WSGI服务器

      python server.py
      
    • 使用客户端访问
      打开浏览器,输入http://localhost:8000/ ,在浏览器正常显示“Hello, World!”

    在这里插入图片描述

    代码简析

    上面的application()函数就是符合WSGI标准的一个HTTP处理函数,它接收两个参数:

    • environ:一个包含所有HTTP请求信息的dict对象
    • start_response:一个发送HTTP响应的函数

    而在application()函数中又调用了start_response函数

    该函数发送了HTTP响应的Header,注意Header只能发送一次,也就是只能调用一次start_response()函数。start_response()函数接收两个参数,一个是HTTP响应码,一个是一组list表示的HTTP Header,每个Header用一个包含两个strtuple表示。

    通常情况下,都应该把Content-Type头发送给浏览器。其他很多常用的HTTP Header也应该发送。然后,函数的返回值b'<h1>Hello, web!</h1>'将作为HTTP响应的Body发送给浏览器。

    有了WSGI,我们关心的就是如何从environ这个dict对象拿到HTTP请求信息,然后构造HTML,通过start_response()发送Header,最后返回Body。

    整个application()函数本身没有涉及到任何解析HTTP的部分,也就是说,底层代码不需要我们自己编写,我们只负责在更高层次上考虑如何响应请求就可以了。

    需要注意的是,application()函数必须由WSGI服务器来调用。有很多符合WSGI规范的服务器,我们可以挑选一个来用。但是我们仅将内置的wsgiref服务器用于测试,使我们编写的Web应用程序立马跑起来。

    1.4 实现WSGI服务器

    为了了解wsgi的工作原理,我们可以参照wsgiref源码,使用Python简单实现一个WSGI服务器

    import socket
    import StringIO
    import sys
    
    class WSGIServer(object):
    
        address_family = socket.AF_INET
        socket_type = socket.SOCK_STREAM
        request_queue_size = 1
    
        def __init__(self, server_address):
            # 创建socket,利用socket获取客户端的请求
            self.listen_socket = listen_socket = socket.socket(self.address_family, self.socket_type)
            # 设置socket的工作模式
            listen_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
            # 绑定socket地址
            listen_socket.bind(server_address)
            # socket active, 监听文件描述符
            listen_socket.listen(self.request_queue_size)
    
            # 获得serve的host name和port
            host, port = self.listen_socket.getsockname()[:2]
            self.server_name = socket.getfqdn(host)
            self.server_port = port
    
            self.headers_set = []
    
        def set_app(self, application):
            self.application = application 
    
        #启动WSGI server服务,不停的监听并获取socket数据。
        def serve_forever(self):
            listen_socket = self.listen_socket
            while True:
                self.client_connection, client_address = listen_socket.accept() #接受客户端请求
                #处理请求
                self.handle_one_request()
    
        def handle_one_request(self):
            self.request_data = request_data = self.client_connection.recv(1024)
            self.parse_request(request_data)
    
            # Construct environment dictionary using request data
            env = self.get_environ()
    
            #给flask\tornado传递两个参数,environ,start_response
            result = self.application(env, self.start_response)
            self.finish_response(result)
    
        #处理socket的http协议
        def parse_request(self, data):
            format_data = data.splitlines()
            if len(format_data):
                request_line = data.splitlines()[0]
                request_line = request_line.rstrip('\r\n')
                (self.request_method, self.path, self.request_version) = request_line.split() ## ['GET', '/', 'HTTP/1.1']
    
        # 获取environ数据并设置当前server的工作模式
        def get_environ(self):
            env = {}
            env['wsgi.version']      = (1, 0)
            env['wsgi.url_scheme']   = 'http'
            env['wsgi.input']        = StringIO.StringIO(self.request_data)
            env['wsgi.errors']       = sys.stderr
            env['wsgi.multithread']  = False
            env['wsgi.multiprocess'] = False
            env['wsgi.run_once']     = False
            # Required CGI variables
            env['REQUEST_METHOD']    = self.request_method    # GET
            env['PATH_INFO']         = self.path              # /hello
            env['SERVER_NAME']       = self.server_name       # localhost
            env['SERVER_PORT']       = str(self.server_port)  # 8888
            return env
    
        def start_response(self, status, response_headers, exc_info=None):
            server_headers = [('Date', 'Tue, 31 Mar 2015 12:54:48 GMT'), ('Server', 'WSGIServer 0.2')]
            self.headers_set = [status, response_headers + server_headers]
    
        #把application返回给WSGI的数据返回给客户端。
        def finish_response(self, result):
            try:
                status, response_headers = self.headers_set
                response = 'HTTP/1.1 {status}\r\n'.format(status=status)
                for header in response_headers:
                    response += '{0}: {1}\r\n'.format(*header)
                response += '\r\n'
                for data in result:
                    response += data
                self.client_connection.sendall(response)
                print(''.join(['> {line}\n'.format(line=line) for line in response.splitlines()]))
            finally:
                self.client_connection.close()
    
    SERVER_ADDRESS = (HOST, PORT) = '', 8888
    
    def make_server(server_address, application):
        server = WSGIServer(server_address)
        server.set_app(application)
        return server
    
    
    if __name__ == '__main__':
        if len(sys.argv) < 2:
            sys.exit('Provide a WSGI application object as module:callable')
        app_path = sys.argv[1]
        module, application = app_path.split(':') # 第一个参数是文件名,第二个参数时长文件内app的命名
        module = __import__(module)
        application = getattr(module, application) # getattr(object, name[, default]) -> value
        httpd = make_server(SERVER_ADDRESS, application)
        print('WSGIServer: Serving HTTP on port {port} ...\n'.format(port=PORT))
        httpd.serve_forever()
    
    

    1.5 生产环境中的Web服务器

    每个web框架都不是专注于实现服务器方面的,因此,在生产环境部署的时候,使用的服务器也不会简单的使用web框架自带的服务器,那么用于生产环境的服务器有哪些呢?

    Gunicorn

    Gunicorn(从Ruby下面的Unicorn得到的启发)应运而生:依赖Nginx的代理行为,同Nginx进行功能上的分离。由于不需要直接处理用户来的请求(都被Nginx先处理),Gunicorn不需要完成相关的功能,其内部逻辑非常简单:接受从Nginx来的动态请求,处理完之后返回给Nginx,由后者返回给用户。

    由于功能定位很明确,Gunicorn得以用纯Python开发:大大缩短了开发时间的同时,性能上也不会很掉链子。同时,它也可以配合Nginx的代理之外的别的Proxy模块工作,其配置也相应比较简单

    uWSGI

    使用C语言开发,和底层接触的更好,配置也比较方便,目前和gunicorn两个算是部署时的唯二之选。由于其可扩展的架构,它能够被无限制的扩展用来支持更多的平台和语言。目前,可以使用C,C++和Objective-C来编写插件

    uWSGI 既不使用wsgi协议也不用FastCGI协议,而是自创了一个uwsgi的协议,uwsgi协议是一个uWSGI服务器自有的协议,它用于定义传输信息的类型(type of information),每一个uwsgi packet前4byte为传输信息类型描述,它与WSGI相比是两样东西。据说该协议大约是fcgi协议的10倍那么快

    主要特点如下:

    • 超快的性能
    • 低内存占用(实测为apache2的mod_wsgi的一半左右)
    • 多app管理
    • 详尽的日志功能(可以用来分析app性能和瓶颈)
    • 高度可定制(内存大小限制,服务一定次数后重启等)

    uWSGI 服务器自己实现了基于uwsgi协议的server部分,因此我们只需要在uwsgi的配置文件中指定application的地址,uWSGI 就能直接和应用框架中的WSGI application通信

    bjoern

    是一个用C语言编写的,快速超轻量级的 Python WSGI服务器。
    它是最快速的,最小的并且是最轻量级的WSGI服务器。有以下特性:

    • 1000 行的C代码
    • 占用内存 600KB
    • 单线程没有其他协同程序
    • 可以绑定到TCP主机:端口地址和Unix套接字
    • 支持HTTP1.0/1.1,包含支持HTTP1.1的分块响应

    如果单纯追求性能,那uWSGI会更好一点,而Gunicorn则会更易安装和结合gevent。在阻塞响应较多的情况下,Gunicorn的gevent模式无疑性能会更加强大。功能实现方面,uWSGI会更多一些,配置也会更加复杂一些。

    2. Web应用开发

    常见的Python Web应用框架:

    • Django:全能型Web框架
    • Flask:一个使用Python编写的轻量级Web框架
    • web.py:一个小巧的Web框架
    • Bottle:和Flask类似的Web框架
    • Tornado:Facebook的开源异步Web框架

    2.1 服务器架构

    在这里插入图片描述

    2.1.1 Nginx

    Nginx(发音同engine x)是一个异步框架的 Web服务器,也可以用作反向代理,负载平衡器 和 HTTP缓存。该软件由 Igor Sysoev 创建,并于2004年首次公开发布。同名公司成立于2011年,以提供支持。

    Nginx是一款免费的开源软件,根据类BSD许可证的条款发布。一大部分Web服务器使用Nginx,通常作为负载均衡器。

    Nginx是一款面向性能设计的HTTP服务器,相较于Apache、lighttpd具有占有内存少,稳定性高等优势。与旧版本(<=2.2)的Apache不同,Nginx不采用每客户机一线程的设计模型,而是充分使用异步逻辑从而削减了上下文调度开销,所以并发服务能力更强。整体采用模块化设计,有丰富的模块库和第三方模块库,配置灵活。 在Linux操作系统下,Nginx使用epoll事件模型,得益于此,Nginx在Linux操作系统下效率相当高。同时Nginx在OpenBSD或FreeBSD操作系统上采用类似于epoll的高效事件模型kqueue。

    Nginx在官方测试的结果中,能够支持五万个并行连接,而在实际的运作中,可以支持二万至四万个并行连接

    反向代理

    在这里插入图片描述

    正向代理是指浏览器主动请求代理服务器,代理服务器转发请求到对应的目标服务器。而反向代理则部署在Web服务器上,代理所有外部网络对内部网络的访问。浏览器访问服务器,必须经过这个代理,是被动的。正向代理的主动方是客户端,反向代理的主动方是Web服务器

    在Python的Web开发中,较为成熟稳定的服务器架构一般是Nginx + uWSGI + Django。而实际上Nginx服务器并不是必须的,直接使用uWSGI + Djang完全是可以的,但这样一来,直接将uWSGI服务器暴露给了浏览器客户端,由此会导致诸多隐患。

    Nginx的优势
    1. 安全问题。客户端对Web服务器的访问需要先经过反向代理服务器,Nginx则只需开放某个接口,uWSGI本身是内网接口,这样可以防止外部程序对Web服务器的直接攻击。
    2. 负载均衡。反向代理服务器可以根据Web服务器的负载情况,动态地把HTTP请求交给不同的Web服务器来处理,前提是要有多个Web服务器。
    3. 提升Web服务器的IO性能。一个HTTP请求的数据,从客户端传输给服务器,是需要时间的,例如N秒,如果直接传给Web服务器,Web服务器就需要让一个进程阻塞N秒,来接收IO,这样会降低Web服务器的性能。如果使用Nginx作为反向代理服务器,先让反向代理服务器接收完整个HTTP请求,再把请求发给Web服务器,就能提升Web服务器的性能。将静态资源发送(js、css、图片等)、动态请求转发以及结果的回复交给Nginx处理,就不需要经过Web服务器。

    附录

    支持WSGI的Web应用框架有很多

    • BlueBream
    • bobo
    • Bottle
    • CherryPy
    • Django
    • Flask
    • Google App Engine’s webapp2
    • Gunicorn
    • prestans
    • Pylons
    • Pyramid
    • restlite
    • Tornado
    • Trac
    • TurboGears
    • Uliweb
    • web.py
    • web2py
    • weblayer
    • Werkzeug

    参考

    [参考资料1]
    [参考资料2]
    [参考资料3]
    [参考资料4]
    [参考资料5]

    展开全文
  • WEB应用中间层的分层架构设计总结

    千次阅读 2017-07-28 15:51:19
    阿堂管理Pos项目团队一年半多时间,由于...在Pos团队时一直比较忙,这段时间在忙于带队开发基于微信公众平台的公司移动业务应用,业余时间又在研究IOS技术,一直没有时间去写点什么了。  正寻思写点什么呢?刚
  • Web应用程序  (1)什么是Web应用程序  应用程序有两种模式C/S、B/S。C/S是客户端/服务器端... Web应用程序一般是B/S模式。Web应用程序首先是应用程序,和用标准的程序语言,如Java、PHP等编写出来 的程序没有什
  • 三种主流Web架构

    万次阅读 2018-01-21 09:48:54
    三种主流Web架构 做WEB好几年了,各种语言...这里说的WEB架构,是指WEB应用开发每种技术独有的资源组织形式(包括文件,数据库,HTTP请求处理等。注意并非OO的开发方式才有架构一说),也许说开发方式更容易让人理
  • 本文将讨论推动现代网络发展创新的一些问题。然后,我们将深入探讨事件驱动型架构 (EDA) 的基本知识,该架构试图通过以新颖的方式思考后端架构来解决这些问题。
  • 系统平台采用前后端完全分离的单页 Web 应用(Single Page Application)架构:前端采用 Html 5、JavaScript、Bootstrap和AngularJS 等国际主流技术实现界面渲染及逻辑控制,后端提供基于REST API及JSON 的服务。...
  • 标准Web系统的架构分层

    万次阅读 多人点赞 2015-06-22 10:30:36
    标准Web系统的架构分层 标准Web系统架构适用于传统的基于WEB浏览器/手机端的CRM系统、ERP系统、SaaS系统、O2O系统、商城系统、物流系统。架构的灵活性和业务适应性决定了不同的系统根据业务形态、访问量、安全性所...
  • 互联网应用架构

    千次阅读 2018-07-26 14:31:30
    互联网应用架构 1. Web服务器和应用服务器的区别 Web服务器的设计目的是提供HTTP内容,应用服务器也可以提供HTTP内容,但不限于HTTP,它还可以提供其他协议支持,如RMI / RPC。 1.1 Web服务器 Web服务器的...
  • Saas系统架构的思考,多租户Saas架构设计分析

    万次阅读 多人点赞 2019-06-14 13:39:35
    很多创业公司都在尝试创建企业级别的应用cRM, HR,销售, Desk Saas系统。很多Saas创业公司也拿了大额风投。毕竟Saas相对传统软件的优势非常明显。 最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都...
  • 网络应用架构一般分为两层架构、三层架构、N层架构。其中B/S架构、C/S架构是两层架构的代表。 一、C/S架构 C/S架构是Client/Server的缩写,翻译过来就是“客户端/服务器”。 C/S架构的业务逻辑主要集中在客户端...
  • 大型web系统架构详解

    万次阅读 多人点赞 2017-06-21 14:41:08
    本博客会逐步推出一系列的关于大型网站架构、分布式应用、设计模式、架构模式等方面的系列文章)  动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,...
  • 主流Web架构详解

    千次阅读 2019-05-27 18:40:28
    主流Web架构详解 WEB程序的架构基本上可以分成以下三类: 一 、基于“组件”(Component ,GUI设计也常称控件)、事件驱动的架构,最常见的是微软的.NET。基本思想是把程序分成很多组件,每个组件都可以触发事件...
  • 而软件开发最大的挑战,就是即能够快速高效地针对需求、环境的变化做出改变,也能够持续提供稳定、高可用的服务。而软件架构,就是软件系统的骨骼与框架。 所谓架构,见仁见智,很难有一个明确或标准的定义;但...
  • web开发框架技术有哪些?

    万次阅读 2018-11-07 16:07:30
    如果你是做Web开发的,Web框架一定会很熟悉,框架是Web架构开发必不可少的工具,不仅可以提高开发效率,还能让开发项目更成熟,并且可以提升代码的可再用性,Web框架开发离不开相应的开发语言,以下是常用的Web...
  • 常用web服务器架构理解

    千次阅读 2018-06-24 17:39:16
    一、服务器架构理解 一个Web项目上线,必须依托于服务器成为互联网之的一个节点,要使我们的应用得以运转,这个节点内容需要进行一系列的工作环境安装配置,而为了目标项目的安全性、稳定性、灵活性,同时考虑...
  • 架构可细分为业务架构应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型  应用架构类型:单体式...
  • Java应用一般架构

    千次阅读 2015-11-09 17:27:23
    当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现。  ...WebService,即“Web 服务”,简写为 WS。从字面上理
  • Web技术整体架构

    千次阅读 2018-05-22 11:16:59
    题记工作也有几多年了,无论是身边遇到的还是耳间闻到的,多多少少也积攒了自己的一些经验和思考,当然,博主并没有太多接触高大上的分布式架构实践,相对比较零碎,随时补充(附带架构装逼词汇)。俗话说的好,...
  • 工作使用了微服务架构,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,同时我也会在github上写一个microservices的应用框架(地址会在后续文章给出)。 这篇文章是对 ...
  • 基于Spring springMVC mybatis三种开源框架,构建java web应用
  • 主流的Web应用程序平台

    千次阅读 2017-09-06 20:15:40
    主流的Web应用程序平台 动态网站应用程序平台的搭建需要使用Web服务器发布网页,而Web服务器软件又需要安装在操作系统上,并且动态网站都需要使用脚本语言对服务器端进行编程,所以也要在同一个服务器中为Web服务器...
  • WEB项目的基本架构

    千次阅读 2014-10-13 13:38:16
    J2EE WEB项目的一般采用B/S(Browser/Server)架构。B/S针对WEB项目的特点,对原C/S(Client/Server)架构进行了改进,从而降低WEB项目的开发成本和维护难度。本文以Apache Web服务器和Tomcat应用服务器为例,介绍...
  • WebService,即“Web 服务”,简写为WS。从字面上理解,它其实就是“基于 Web的服务”。而服务却是双方的,有服务需求方,就有服务提供方。服务提供方对外发布服务,服务需求方调用服务提供方所发布的服务。如果说得...
  • 这个模块一般位于支付网关之后,支付渠道之前。 它根据支付能力将不同的支付渠道封装成统一的接口,通过支付网关来对外提供服务。所以,从微服务的角度,支付产品本身也是一个代理模式的微服务,它透过支付网关响应...
  • 大型Java web项目分布式架构演进

    万次阅读 2017-01-22 09:41:41
    系统架构演化历程-初始阶段架构 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP 特征: 应用程序、数据库、文件等所有的资源都在一台服务器上。 描述: 通常服务器操作...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 243,638
精华内容 97,455
关键字:

web应用中一般采用架构的是