① 如何用IIS架构WEB网站
亲，对详情描述里的两问题的回答：
1、网站发布首先需要解决域名解析的问题，做好的网站要发布且在个人电脑里可以选择花生壳域名软件来映射内外网地址发布。详情请网络“花生壳”。
2、右击浏览可以的话，网站主目录就没有问题。那么
a.你的网站TCP端口不是默认的80，请如下图一改回即可。
b.当然也可以在输完IP地址后加 “ : 端口号 ”来访问网页。
c.如果因为安全级别问题可以将internet属性里的安全级别调低点，并将网址添加到受信任的站点里。
对标题问题的回答：
可以使用服务器系统来搭建，web网站可以有三种方式表达，IP地址、端口、主机头。
以主机头实验为例如下图
服务器设置
② web前端框架有哪些
目前比较流行的前端框架是Angular、React、Vue、Bootstrap
如果基础建议别看框架，先学习html、css、js（可以暂时不会写，但必须会用），能独立完成页面编码之后，再学习框架
③ 如何架构web服务器
一种是将服务器托管到机房，非常省心；
一种方法就是找电信接个专网，独立的ip，然后让网管绑定域名就可以了。像qq公司就是类似这种，他们有自已的机房.
当然你自己在服务器上还得装很多软件
比如网站需要的运行环境：iis6.0
.net运行框架framewor
数据库：mysql或者sqlserver
文件上传下载软件：leapftp
还有服务器的安全你得设置好，很多问题的，不是那么简单的事情.
④ 简述WEB系统的架构原理
这个话题太大了。
一般来说，WEB系统，主要是指后端，前端就是各种浏览器了。
那么简单来讲，只要是能与浏览器通过网络交互的系统，都可以算是WEB系统。最简洁的就是用NODEJS写一个echo,就是客户端发什么内容，就回什么内容。
而在实际应用中，WEB系统的架构，一般有这么几个部分：负载均衡、授权验证（可选）、静态内容服务、动态内容服务（业务逻辑）、数据库、运维后台。
1）负载均衡是为了改善用户体验、充分利用服务器资源，主要功能是将新的请求转发到不那么忙的服务器进行处理。
2）授权验证，是在对浏览器发起的请求进行授权校验，如果不是合法的请求，就予以拒绝或者重定向至登录页面。
3）静态内容服务，是指图片、CSS等不会根据不同用户而变化的静态内容，将其直接返回给用户。因为不需要进行逻辑判断，性能主要取决于I/O读写，响应可以非常快。超大型网站，也会把一部分动态内容，例如对访问量大的新闻页，做静态处理，以提升响应速度。静态内容服务的典型是CDN。
4）动态内容服务，是根据用户请求的不同，而进行响应的业务逻辑处理。比如对用户数据的CRUD(增删查改）。这是绝大多数WEB系统的核心所在，一般会调用数据库和数据缓存。具体实现会根据业务需要而变化，也可以变得非常复杂。
5）数据库，是数据所在，既有经典的关系型传统数据库系统，也有为了提升访问性能、减轻的内存数据库。
6）运维后台，是为了方便监控运行状态、升级维护系统，不直接参与对外服务。
先写这么多吧。有具体的问题了，可以再问。
⑤ 兰州北大青鸟分享web前端多端编程开发框架结构
随着我们对web前端编程开发技术的掌握，越来越多的框架语言和架构方式被我们所熟知。
下面兰州北大青鸟http://www.kmbdqn.cn/就一起来了解一下，web前端开发的一些常见框架结构。
1.全包型这类框架大的特点就是从底层的渲染引擎、布局引擎，到中层的DSL，再到上层的框架全部由自己开发，代表框架是Qt和Flutter。
这类框架优点非常明显：性能(的上限)高;各平台渲染结果一致。
缺点也非常明显：需要完全重新学习DSL(QML/Dart)，以及难以适配中国特色的端：小程序。
这类框架是原始也是纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能大可能地去保证开发和跨端体验一致。
但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。
2.Web技术型这类框架把Web技术(JavaScript，CSS)带到移动开发中，自研布局引擎处理CSS，使用JavaScript写业务逻辑，使用流行的前端框架作为DSL，各端分别使用各自的原生组件渲染。
代表框架是ReactNative和Weex，这样做的优点有：开发迅速;复用前端生态;易于学习上手，不管前端后端移动端，多多少少都会一点JS、CSS。
缺点有：1.交互复杂时难以写出高性能的代码，这类框架的设计就必然导致JS和Native之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得UI无法在16ms内及时绘制。
ReactNative有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。
2.由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有一种高。
3.JavaScript编译型这类框架就是我们这篇文章的主角们：Taro、WePY、uni-app、mpvue、chameleon，它们的原理也都大同小异：先以JavaScript作为基础选定一个DSL框架，以这个DSL框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。
⑥ web前端开发开发技术架构有哪些
前端的应用非常广泛，基本网站、APP、HTML5小程序等都需要前端开发，所以只要是互联网产品基本都需要前端。
前端程序猿切页面写页面，Web上、H5上的炫酷效果，是前端开发大展身手的地方。最常见的用于前端开发的技术组合是：
HTML+CSS+JavaScript。
web前端是在开发人员中最直接面向产品、面向用户的设计人员，一个开发团队的成果是要靠web前端去展现，因为用户不会去关心后台的处理有多么强大。
后端开发是写后台，各种业务逻辑、数据处理、模块接口、客户端接口等等。后端开发者通常精通于一种Web编程语言和一个数据库管理系统。电商平台点击筛选条件下面为你筛选出来的宝贝的功能以及付款人数数据的变化等都是由后台来实现提供的。
目前web产品交互越来越复杂，用户使用体验和网站前端性能优化这些都得靠web前端去做。
前端开发则是网站的前台代码实现，包括基本的HTML和CSS以及JavaScript/ajax，最新的高级版本HTML5、CSS3，以及SVG等。
前端开发需要学习的技术
1 掌握基本web前端开发技术：HTML、CSS、JavaScript、DOM、BOM、AJAX等，而且要了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug
2 必须掌握网站性能优化、SEO和服务器端开发技术的基础知识
3 必须学会运用各种web前端开发与测试工具进行辅助开发
4 除了掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持等
5 未来web前端开发工程师还要研究HTML5、web视觉设计、网站配色、网站交互设计模式等相关技术
web前端有广阔的发展空间，app、小程序、移动端、pc端等都网站是需要前端技术的开发支持才能够完成，技术门槛相对较低、需求量较大，薪资待遇良好。只要是互联网端的客户界面，就需要前端来制作完成，前端开发的编程量不大，但是需要部分编程，入门简单，但是要学的深入需要一个过程。
Web前端招聘岗位
• 前端开发工程师、Web开发工程师、网页开发工程师、HTML开发工程师...
• H5开发工程师、移动应用开发工程师、App开发工程师、小程序开发工程师...
• JS开发工程师、Vue.js开发工程师、Node.js开发工程师、前端架构师...
• 小游戏开发工程师、数据可视化开发工程师、WebGL开发工程师、WebVR开 发工程师、Web安全工程师...
⑦ 大型java web系统架构该如何设计
其实操作起来不难。
”健壮性“：用现成的流行的框架。大家实践检验过的一定很robust。
”拓展性“：就是说你要对你用的框架很熟，要明白原理，甚至可以自己修改，实现功能。这个要花时间下功夫。
“易维护”：写好注释，做好文档。平时稍微用点心就可以做好。
“版本控制”：这有现成的工具，比如git。
⑧ Web应用框架的架构
基于请求的框架较早出现，它用以描述一个web应用程序结构的概念和传统的静态Internet站点一样，是将其机制扩展到动态内容的延伸。对一个提供HTML和图片等静态内容的网站，网络另一端的浏览器发出以URI形式指定的资源的请求，Web服务器解读请求，检查该资源是否存在于本地，如果是则返回该静态内容，否则通知浏览器没有找到。Web应用升级到动态内容领域后，这个模型只需要做一点修改。那就是web服务器收到一个URL请求（相较于静态情况下的资源，动态情况下更接近于对一种服务的请求和调用）后，判断该请求的类型，如果是静态资源，则照上面所述处理；如果是动态内容，则通过某种机制（CGI、调用常驻内存的模块、递送给另一个进程如Java容器）运行该动态内容对应的程序，最后由程序给出响应，返回浏览器。在这样一个直接与web底层机制交流的模型中，服务器端程序要收集客户端籍get或post方式提交的数据，转换，校验，然后以这些数据作为输入运行业务逻辑后生成动态的内容（包括HTML、JavaScript、CSS、图片等）。
基于组件的框架采取了另一种思路，它把长久以来软件开发应用的组件思想引入到web开发。服务器返回的原本文档形式的网页被视为由一个个可独立工作、重复使用的组件构成。每个组件都能接受用户的输入，负责自己的显示。上面提到的服务器端程序所做的数据收集、转换、校验的工作都被下放给各个组件。现代web框架基本上都采用了模型、视图、控制器相分离的MVC架构，基于请求和基于组件两种类型大都会有一个控制器将用户的请求分派给负责业务逻辑的模型，运算的结果再以某个视图表现出来，所以两大分类框架的区别主要在视图部分，基于请求的框架仍然把视图也就是网页看作是一个文档整体，程序员要用HTML、Javascript和CSS这些底层的代码来写“文档”，而基于组件的框架则把视图看作由积木一样的构件拼成，积木的显示不用程序员操心（当然它们也是由另一些程序员开发出来的），只要设置好它绑定的数据和调整它的属性，把他们大大从编写HTML、Javascript和CSS这些界面的工作中解放出来。 基于请求的和基于组件的两种框架各有优劣。虽然一眼看上去后者有很大的吸引力，普通的web开发人员只要使用专门的公司或开源组织提供的组件就可以轻松开发出好用漂亮的界面，但是有几种因素综合起来不利于这种理想中的方案。要编写一个没有潜在问题的、跨浏览器的、显示美观并且有足够灵活性可以调整的服务器端组件是需要高水平的技能、丰富的经验和较多时间的，即使付出这些成本，也不能完全避免使用者失望的情况。
综合来看，基于请求的框架要程序员自己动手的地方比较多，但也因此可以更精细地控制HTML、CSS和Javascript这些最终决定应用程序界面的代码，特别是如果要在界面上有创新，尝试新的视觉效果和用户操作，必然选择基于请求的框架。基于组件的框架可以提高开发界面的效率，前提是选用的组件质量优秀。
⑨ 如何开发一个Python web框架
首先你需要知道一个Web应用基本的请求处理流程。以最简单最原始的动态网页为例，你点击链接（GET），提交表单（POST），就是与服务器端建立了连接之后发送了一个HTTP请求（RFC2616 5.1节，之后都以HTTP 1.1为例），里面至少有方法（动词，就是GET啦POST什么的，详见RFC2616第9节），地址（URL），HTTP版本，还可能带上Cookie（会话的一般实现机制），缓存相关的信息（RFC2616 13节），User-Agent串等等一堆信息。对于POST请求我们还有表单内容作为请求实体（RFC2616 7.2节），里面是你填写的表单内容。
于是我们有了一些关于请求的数据，不过现在一般来讲这些数据还在前端服务器（反向代理，比如nginx，暂且忽略掉负载均衡，反正是透明的，也不考虑裸WSGI容器直接扛请求的情况）的手上，还没有传进后端语言（这里是Python）。我们就针对每一种语言都有特定的机制，用来将HTTP的请求信息映射到相应的编程语言范畴，叫做Web服务器界面（Web server interface），通用如CGI/FCGI/SCGI，特定于某一语言如WSGI/PSGI/Rack/...，特定于某一操作系统如ISAPI（这货还活着？），一些已经不再使用的就不提了。总之在Python世界里这就是WSGI（PEP 3333, Web Server Gateway Interface），它就定义了Python语言与Web服务器之间的界面。在WSGI里，
请求的处理过程被映射为对应用callable的调用（application(environ, start_response)，知乎不支持inline代码块？）；
请求信息被映射到environ字典中的相应键值，比如请求方法被映射到environ['REQUEST_METHOD']，请求的“相对路径”被映射到environ['PATH_INFO']（过度简化；暂且不提WSGI应用挂载点，框架层一般也不用关心这个，挂载WSGI应用一般是WSGI容器如gunicorn、uWSGI之类组件的工作）；
发送响应头的动作被映射到调用start_response(status, response_headers)（不考虑可选的第三个参数异常信息）；
返回响应数据被映射到application返回iterable的动作。
于是响应便从Python返回到Web服务器，再被发送回浏览器，浏览器将响应内容渲染，一个请求就完成啦。
有了这样的感性认识，那么我们作为Python Web开发框架的作者，要做的事情就是在WSGI规范的基础之上，提供尽可能便捷的开发手段和尽可能低的框架开销，也即我们的代码将要工作在WSGI与业务逻辑的中间层。架构上，Web开发框架或多或少都遵循MVC的设计模式（Django管它叫MTV，其实差不多）。同时，由于框架位于中间件的位置，加上其鼓励模块化与代码复用的性质，自然需要为常见的HTTP操作提供抽象。这里就可以展开一些话题：
请求路径到view/controller的映射，请求参数的解析（routing，也叫路由）。
正则匹配的方案，比如Django内置了一个简单的正则表达式解析组件，能解析一般常见语法的正则表达式，把capturing groups解析成位置参数，named capturing groups解析成关键字参数。
也有DSL的方案，比如Werkzeug的路由组件。
请求实体的处理。表单解析，配合Web服务器进行上传文件处理。
正常的urlencoded表单，JSON表单，text/plain数据，multi-part表单
multi-part附件，附件操作API
大文件上传（这个一般会被前端服务器保存在磁盘上的临时文件里，比方说nginx就是这么实现的）。
会话。HTTP是无状态（stateless）的，这个特点非常重要。如果没有会话，你连续做几个请求，却没有手段证明你们是同一个人/同一台机器（你完全可能是代理服务器）。
存储会话数据的会话后端（内存数据结构？文件？RDBMS？Redis？Memcache？）
安全机制（HMAC什么的，可以参考beaker的secure cookie实现）
请求处理流程中的会话中间件（从Cookie中提取会话，从query string中提取会话，从自定义头中提取会话，等等）
View/Controller界面。发挥你的创造力，用上你的工程经验。
Function-based or Class-based views? 参考：Django, Bottle, web.py, Tornado等一票框架的做法
框架的可选机制与服务如何暴露，
装饰器？（比如@login_required 这种额外要求）
回调？（能想到的只有Tornado和Twisted这种异步框架做事情的方式，还有整个JS生态系统都是回调（不考虑Promise什么的）的思路）
传入应用（业务逻辑）层的数据结构如何设计？（HttpRequest等价物，名字可能记不清了）
响应数据结构如何设计？（HttpResponse等价物，同上）
数据库操作封装。Web应用基本都是数据为中心，这个组件非常有必要，也是撰写可复用代码必须的一环，毕竟光是框架抽象了，数据库操作还是裸SQL什么的，到时候生产环境一换（比如MySQL变pgsql）还不是傻眼。
关系型数据库。一站式解决方案参考：Django ORM、SQLAlchemy；轻量级解决方案参考各数据库Python绑定。
非关系数据库。各数据库Python绑定（pymongo, riak, redis-py之类），这个没什么可替代方案了，因为本来各种NoSQL库都是适应某一特殊需求设计的，没什么互相替换的必要，那意味着重新进行技术选型。
未完待续
接下来的内容：
主要响应AJAX/API请求的框架设计思路
Python下实时Web框架思路
框架设计哲学
框架性能分析方法
本人才疏学浅，大项目没做过，小项目也没怎么起飞过，请各位阅读我的观点时务必留心。读到最后非常感谢。