物联网百问百解(1)

2020-12-02  本文已影响0人  山岳之心

问题一: 最简单的web1.0互联网如何架构?

web1.0 时代,用户通过在浏览器里输入网址(URL)来访问门户网站,获得信息。所以首先我们需要了解,用户访问互联网时,网络的工作流程是怎样的。

1. 用户访问的网络工作流程

此工作流程可以分解为7个步骤:

  1. 用户在浏览器的地址栏输入网址(即URL)
  2. 浏览器将URL转发至服务器上的路由器,路由器将URL转换为HTML表单,再将此表单转发到服务器上的资源管理器。
  3. 资源管理器将HTML表单解析为数据模型,将对应数据模型的请求发送到数据库,请求相应的数据。
  4. 数据库根据资源管理器发送来的请求返回对应的数据给资源管理器。
    5.资源管理器将数据库返回的数据填入HTML表单,并返回给路由器。
  5. 路由器转发此HTML表单到浏览器。
  6. 浏览器解析HTML表单,启用浏览器自带的CSS, JavaScript等工具渲染此HTML表单,呈现给用户的实质上等价于是一个PPT。

在标准的术语中,浏览器被划分为两个部分,一个是面向用户的表单系统,它就是一个显示效果,另一个被称为web服务器,而上面提及的服务器也被称作是web应用服务器。

2. 实体及对应的技术

其次,要想实现以上的步骤,必须明白这个过程中涉及的实体以及对应的技术。

  1. 用户(无需技术开发,也无需配置)
  2. 浏览器(包含显示UI, 配置uwsgi, nginx等)
  3. 路由器(HTTP连接,解析URL对应到业务层的HTML表单,对应浏览器的接口,对应资源管理器的接口)
  4. 资源管理器(连接路由器,接收路由器下发的HTML表单,连接数据库,解析HTML表单为数据模型,将数据模型请求发送到数据库,接受数据库返回的数据,填入HTML表单,返回此表单到路由器)
  5. 数据库(MySQL, MongoDB, 增删改查技术,优化,视图,索引...)

3. 上下文架构

在确定实体以及流程以后,就可以来画上下文架构图(参见C4架构)了。

@startuml "enterprise"
    !include ./plantuml_C4/c4_context.puml
    !include ./plantuml_C4/c4_container.puml
    !include ./plantuml_C4/full-plantuml.puml
    SCALE 450 WIDTH
    LAYOUT_TOP_DOWN
    title 用户访问网页的上下文架构图
    Actor(User, 用户, "在网页输入以及\n获得网页输出")
    System_Boundary(c1, "网页前端层") {
        Container(UI_inputs, "UI及表单(UI)", "HTML, CSS, JS", "客户输入\n渲染HTML")
        Container(Web_Server, "Web服务器(WS)", "Uwsgi, Nginx", "转发代理及\n 负载均衡")
    }
    
    System_Boundary(c2, "后台服务层") {
        Container(Router, "路由器(Router)", "Django", "连接前端和\n资源管理器")
        Container(APP_Server, "资源管理器(RA)", "ORM, PyMysql", "请求/接收数据\n连接后台与数据库")
        Rel_R(Router, APP_Server,"下行HTML","空白表单")
        Rel_L(APP_Server, Router, "上行HTML","完成表单")        
    }

    ContainerDb(Database, "数据库\n或文件系统","MySQL, Redis...")
    Lay_D(User, c1)
    Lay_D(c1,c2)
    Dependency(User,UI_inputs,"输入/获取")
    Rel_L(Web_Server,UI_inputs,"上行发送HTML","已完成的表单")
    Rel_D(UI_inputs, Router,"下行发送URL")
    Rel_U(Router, Web_Server,"上行发送HTML")
    Dependency(APP_Server,Database,"请求/返回")

@enduml

在上面的架构设计中,我们混合使用了依赖关系和关联关系。这对于描述来说是容易理解的,但对于开发来说,这样的架构是不合理的。

所以一般还需要对上下文图进行依赖翻转的操作。

我们希望,开发所看到的架构图是依赖关系图。并且明确哪些组件是可以被替换的,哪些组件是核心应用,不可替换的。

一般来说,我们需要可替换浏览器,数据库,以适应核心功能的迁移最简化。

所以我们将上面的图转化为标准的解耦架构图。

@startuml "enterprise"
    !include ./plantuml_C4/c4_context.puml
    !include ./plantuml_C4/c4_container.puml
    !include ./plantuml_C4/full-plantuml.puml
    SCALE 700 WIDTH
    LAYOUT_LEFT_RIGHT
    'LAYOUT_TOP_DOWN
    title 用户访问网页的上下文解耦架构图
    Actor(User, 用户, "在网页输入以及\n获得网页输出")
    System_Boundary(c1, "网页前端层") {
        Container(UI_inputs, "UI及表单(UI)", "HTML, CSS, JS", "客户输入\n渲染HTML")
        Container(Web_Server, "Web服务器(WS)", "Uwsgi, Nginx", "转发代理及\n 负载均衡")
    }
    
    System_Boundary(c2, "后台服务层") {
        Container(Router, "路由器(Router)", "Django", "连接前端和\n资源管理器")
        Container(APP_Server, "资源管理器(RA)", "ORM, PyMysql", "请求/接收数据\n连接后台与数据库")
    }
    ContainerDb(Database, "数据库\n或文件系统","MySQL, Redis...")
    Dependency(User,UI_inputs,"输入/获取")
    AssociationH(UI_inputs, Web_Server,"上行HTML","下行URL")
    Dependency(Web_Server, Router, "上行HTML","下行URL")
    DependencyBack(APP_Server,Database,"请求/返回","Data Model")
    AssociationH(APP_Server, Router, "HTML")
    

@enduml
上一篇下一篇

猜你喜欢

热点阅读