网站视觉优化怎么做,电子商务网站建设参考文献2018,东莞商城网站建设哪里比较好,c2750服务器做网站行吗文章目录前言一、软件1.1、何为软件#xff1f;1.2、计算机软件的分类1.2.1、系统软件1.2.2、应用软件1.3、软件系统体系结构1.3.1、C/S 结构#xff08;桌面应用程序#xff09;1.3.2、B/S 结构#xff08;Web 应用程序#xff09;1.3.3、Web 服务器与数据库服务器1.3.4、…
文章目录前言一、软件1.1、何为软件1.2、计算机软件的分类1.2.1、系统软件1.2.2、应用软件1.3、软件系统体系结构1.3.1、C/S 结构桌面应用程序1.3.2、B/S 结构Web 应用程序1.3.3、Web 服务器与数据库服务器1.3.4、Web 应用的请求流程1.3.5、Web 应用处理静态资源请求1.3.6、Web 应用处理动态资源请求1.3.7、RIA 应用1.3.8、APP二、基于 Web 的软件开发2.1、B/S 架构工作原理2.2、网络游戏架构图2.3、游戏开发的核心三、Java 常用框架解析3.1、为什么使用框架框架为何经久不息3.2、现阶段流行的框架有哪些3.2.1、“一类经典永流传”——SpringMVC、Spring、Mybatis3.2.2、“长江后浪推前浪”——微服务、分布式、缓存、项目管理、中间件3.2.3、“好风凭借力”——脚手架的使用3.2.4、“送我上青云”——传统框架的迭代使用3.3、如何拿捏住框架的“七寸”四、数据库与数据仓库4.1、数据库分类及排行榜4.1.1、SQL 关系型数据库4.1.2、NoSQL 非关系型数据库4.2、常见关系型数据库使用技巧4.2.1、关联关系的存在4.2.2、主键和外键4.2.3、范式和冗余4.2.4、表列数量4.2.5、数据类型4.2.6、性能优化4.3、如何进行数据库性能调优4.3.1、where 子句的使用4.3.2、数字闭区间的使用4.3.3、少用 in exists4.3.4、碎片问题、oracle 高水位问题4.3.5、建立索引要谨慎4.3.6、日期的处理4.4、数据库仓库与大数据有何关联4.4.1、数据库4.4.2、数据仓库4.5、服务器架构演变解析4.5.1、单节点4.5.2、分布式4.4.3、微服务五、新一代前后端分离5.1、前后端分离知多少5.2、内容展示和业务逻辑的分离5.3、前端业务和后端业务的分离5.3.1、优势5.3.2、应用5.3.3、存在的挑战5.4、越分越简单还是越复杂总结前言 “古来青史谁不见今见功名胜古人。”Java 激荡三十年我们一起来回顾 Java 开发的历程。总结前人智慧引领前进之路本文作为 Java 全栈入门第一课全栈工程师、Java 后端工程师面试第一课希望能有“等闲识得东风面万紫千红总是春”的效果。 一、软件
1.1、何为软件
一系列按照特定顺序组织的计算机数据和指令的集合。
1.2、计算机软件的分类
计算机软件分为系统软件和应用软件两大类。
1.2.1、系统软件 系统软件是指控制和协调计算机及外部设备,支持应用软件开发和运行的系统是无需用户干预的各种程序的集合主要功能是调度监控和维护计算机系统负责管理计算机系统中各种独立的硬件使得它们可以协调工作。 系统软件使得计算机使用者和其他软件将计算机当作一个整体而不需要顾及到底层每个硬件是如何工作的。
比如我们常见的一些操作系统。 1.2.2、应用软件 应用软件是为满足用户不同领域、不同问题的应用需求而提供的那部分软件。 它可以拓宽计算机系统的应用领域放大硬件的功能。
比如办公室软件、互联网软件、多媒体软件、分析软件、协作软件、商务软件等。 1.3、软件系统体系结构 软件体系结构是具有一定形式的结构化元素即构件的集合包括处理构件、数据构件和连接构件。 处理构件负责对数据进行加工数据构件是被加工的信息连接构件把体系结构的不同部分组合连接起来。
相比较于“软件架构”,“软件体系结构”一词多用于学术研究领域使用“软件架构”多用于工程实践领域二者的外文名都是“software architecture”在 IEEE 中的定义均为“一个系统的基础组织包含各个构件、构件互相之间与环境的关系还有指导其设计和演化的原则。”
1.3.1、C/S 结构桌面应用程序
C/S Client/Server结构即大家熟知的客户机和服务器结构。
通过它可以充分利用两端硬件环境的优势将任务合理分配到 Client 端和 Server 端来实现降低了系统的通讯开销。 目前大多数应用软件系统都是 Client/Server 形式的两层结构在此我们就不得不提到目前在国内使用 C/S 架构的鼻祖应用——腾讯 QQ。
发展方向由于现在的软件应用系统正在向分布式的 Web 应用发展Web 和 Client/Server 应用都可以进行同样的业务处理应用不同的模块共享逻辑组件因此内部的和外部的用户都可以访问新的和现有的应用系统通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
1.3.2、B/S 结构Web 应用程序
B/SBrowser/Server结构即浏览器和服务器结构。它是随着 Internet 技术的兴起对 C/S 结构的一种变化或者改进的结构。
在这种结构下用户工作界面是通过 WWW 浏览器来实现极少部分事务逻辑在前端Browser实现但是主要事务逻辑在服务器端Server实现形成所谓三层结构。这样就大大简化了客户端电脑载荷减轻了系统维护与升级的成本和工作量降低了用户的总体成本TCO。 1.3.3、Web 服务器与数据库服务器
在上面的介绍中我们说到了两类服务器那么这两类服务器各是什么有何作用呢
Web 服务器在 PC 机上安装了 Web 服务的软件这 PC 机就是称为 Web 服务器。 数据库服务器在 PC 机上安装了数据库管理服务软件这 PC 机就称为数据库服务器。
1.3.4、Web 应用的请求流程
我们开发 Web 应用其请求和处理响应的流程即为下图所示 而我们在 Web 应用的请求流程中对于不同形式的资源的处理也是具有明确针对性的。
1.3.5、Web 应用处理静态资源请求 1.3.6、Web 应用处理动态资源请求 1.3.7、RIA 应用
RIARich Internet Application富网络应用。RIA 是 Rich Internet Applications 的缩写翻译成中文为富因特网应用程序Macromedia 中文网站翻译为 Rich Internet 应用程序。 传统网络程序的开发是基于页面的、服务器端数据传递的模式把网络程序的表示层建立于 HTML 页面之上而 HTML 是适合于文本的传统的基于页面的系统已经渐渐不能满足网络浏览者的更高的、全方位的体验要求了这就是被 Macromedia 公司称之为的“体验问题”“Experience Matters”而富因特网应用程序Rich Internet Applications缩写为 RIA的出现也就是为了解决这个问题。
RIARich Internet Application富互联网应用系统技术允许我们在因特网上以一种像使用 Web 一样简单的方式来部署富客户端程序。这是一个用户接口它比用 HTML 能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。无论将来 RIA 是否能够如人们所猜测的那样完全代替 HTML 应用系统对于那些采用胖客户端技术运行复杂应用系统的机构来说RIA 确实提供了一种廉价的选择。
1.3.8、APP
对于 APP 的发展整体我们可以将其分为 4 个阶段如下图所示 从早期的单服务原生 APP 和 Web APP 到现在微信等第三方软件集成的小程序再到三者均有的混合多服务 APP技术的发展在不断地适应市场的发展与消费者的需求。
二、基于 Web 的软件开发
2.1、B/S 架构工作原理
在 Java 这样的跨平台语言出现之后B/S 架构管理软件更是方便、快捷、高效。
我们在此对基于 Web 的软件开发 B/S 架构工作原理进行深度剖析 以目前的技术看局域网建立 B/S 结构的网络应用并通过 Internet/Intranet 模式下数据库应用相对易于把握、成本也是较低的。它是一次性到位的开发能实现不同的人员从不同的地点以不同的接入方式比如 LAN, WAN, Internet/Intranet 等访问和操作共同的数据库它能有效地保护数据平台和管理访问权限服务器数据库也很安全 。
2.2、网络游戏架构图
对于网络游戏而言作为广大用户我们良好的体验性是处于第一位的。
首先想到的就是游戏要实时交互画面的同步实时性更高。画面要不卡顿、低延迟。 这样的话局内人数的限定要求、画面、场景要求就会大大提高同时基于的 TCP、UCP 的底层数据交互更为频繁。这就对设备 CPU、内存和网卡等要求更为苛刻。 而游戏架构设计不合理以及架构本身存在的问题就会造成内存泄漏导致设备 CPU 一直在高速运算对于用户而言显而易见的就是表现为手机用一段时间发热、发烫。
“为发烧而生”这也就是为什么广大厂商都在挤破头的搞芯片研发、CPU 研发的原因。
也正如我所之前在华为云社区微话题所提到的“大型联网游戏部署在云服务上如何在服务端大大提高 FPS以提高玩家游戏体验除了 5G 技术的支持云服务又该如何应对”
如果有同学想涉足或者转战游戏开发领域这些问题就是你要考虑和掌握的技术点。
同时以下我所提到的游戏开发核心更需要铭记在心。
2.3、游戏开发的核心
游戏的设计以及内容是最重要脱离了技术所有的都是空谈程序是骨美术是肉而策划是灵魂讲好故事很多人在听喜欢看想体验。
三、Java 常用框架解析
3.1、为什么使用框架框架为何经久不息
Java 模块化上的欠缺。Java 类库虽强大但其模块化较为欠缺。对于数据的封装和查询等方面较为不足。提高开发效率。传统的 JSPServlet 较为臃肿而框架使用轻巧的同时查询的效率更高。提升性能。直接使用底层语言进行开发若开发者经验不足无法全面考虑到可能存在的问题以及问题该如何解决。比如我们老生常谈的内存泄漏GC 处理的问题而使用框架把这些流程已经完善开发者只需要去专注系统与应用的业务流程即可。解决具体问题。框架可以解决掉较为简单的逻辑结构。例如使用 Shiro 直接就可以实现登陆、注册等功能没有必要多费时间重新写一遍。
3.2、现阶段流行的框架有哪些
3.2.1、“一类经典永流传”——SpringMVC、Spring、Mybatis
SSM 这是最为经典的三大框架也是作为全栈工程师、Java 后端工程师必须和首要掌握的框架。
SpringMVC——负责视图层Spring——负责业务层Mybatis——负责数据层
3.2.2、“长江后浪推前浪”——微服务、分布式、缓存、项目管理、中间件 近年来大量新技术的迭代和更新应用到了企业级项目中。微服务、分布式、缓存、项目管理、中间件等。
Dubbo——微服务Maven——良好的项目管理工具Log4j——日志处理Ehcache——处理内存缓存Redis——分布式缓存Shiro——模板快速实现登录注册、加密等功能
虽说“面试造火箭”但这也是全栈工程师、Java 后端工程师面试必问知识点。
3.2.3、“好风凭借力”——脚手架的使用
Spring Boot——可以单独使用集成其他框架适用于微服务Spring Cloud——依赖于 Spring Boot基于脚手架开发者可以在开发前指定框架、数据库等内容适用于大项目分布式操作
3.2.4、“送我上青云”——传统框架的迭代使用
这就是用到了一些老的框架比如我们之前掌握的 Struts、Struts2、Hibernate 等。
新的技术离不开老技术的核心我们需要切实的掌握老技术自行在开发中进行替换和迭代处理。
3.3、如何拿捏住框架的“七寸”
说了这么多框架换来换去我们所谓的“软件开发”即为数据的流转如下图所示 问作为架构师学习全栈内容何时“炉火纯青”
答当你能够理解各层框架所处的位置及其作用并且可以灵活应用的时候就可以。
四、数据库与数据仓库
4.1、数据库分类及排行榜
我们最为常见的三类关系型数据Oracle、MySQL、Microsoft SQL Server。
以下是 2021 年 1 月DB-engines 数据库排名 我们可以看到 Oracle、MySQL、Microsoft SQL Server 三大数据库稳居榜首分布式数据库 Redis 趋于上升。这也侧面表现出的就是大数据以及分布式的迅速发展。
4.1.1、SQL 关系型数据库 关系型数据库是指采用了关系模型来组织数据的数据库其以行和列的形式存储数据以便于用户理解关系型数据库这一系列的行和列被称为表一组表组成了数据库。用户通过查询来检索数据库中的数据而查询是一个用于限定数据库中某些区域的执行代码。 4.1.2、NoSQL 非关系型数据库 NoSQL泛指非关系型的数据库。随着互联网 web2.0 网站的兴起传统的关系数据库在处理 web2.0 网站特别是超大规模和高并发的 SNS 类型的 web2.0 纯动态网站已经显得力不从心出现了很多难以克服的问题而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL 数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战特别是大数据应用难题。 4.2、常见关系型数据库使用技巧
我们在此总结较为常见关系型数据库需要着重注意的几个问题以及使用技巧。
4.2.1、关联关系的存在
关联关系这个是必须的key 与 value 之间必须具有的对应关系。
关系模型可以简单理解为二维表格模型而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。
4.2.2、主键和外键
这是唯一标识一个元组的标识。
很多企业对于外键可能会有额外的业务要求比如强制外键多见于金融领域提高查询的安全性。
4.2.3、范式和冗余
数据库的几范式什么时候冗余什么时候不冗余
4.2.4、表列数量
在建库的时候要控制数量尤其注意列的数量不要太多。积极去和和项目经理进行协调。
对于大数据量进行拆表、建立主从表、进行多表查询。尽量减少后期查询性能低下的问题。
4.2.5、数据类型
datetime、timestamp 的使用为什么使用这个
4.2.6、性能优化
掌握和进行不同数据库性能优化的技术如进行 SQL 调优进行查询优化处理方案优化等等。
4.3、如何进行数据库性能调优
数据库性能调优是一个大的方向点里面包含的内容涉及较为广泛以下仅提较为常见的几种优化方式。
4.3.1、where 子句的使用
数据库在解析 SQL 语句的时候是从后往前进行的即 where 之后的先开始解析。 所以我们可以添加确定的筛选条件在从后往前解析的时候提升查询效率。
4.3.2、数字闭区间的使用
用 ≥ 等于替代 用 ≤ 代替 不要让数据库系统去判断值的情况使用定值提升查询效率。
可能在数据量小的情况下优势不明显但是在海量数据的情况下提升效率的百分比是惊人的。
4.3.3、少用 in exists
进行联合查询用 left/right join 来实现替代。
4.3.4、碎片问题、oracle 高水位问题
这个问题相信进行实战开发有一段时间的同学有体会。
何为碎片问题oracle 高水位问题
在业务表业务量较大频繁更新数据的情况下会有个别的“碎片”长期存在于数据库系统中不去使用占用资源空间。 大量的碎片就会造成数据库系统查询效率极其低下。即“一棵大树叶子没了树枝还在”。叶子都没了要树枝干啥 我们要及时清理碎片这也就是 oracle 的高水位问题。对于碎片处理不同的数据库系统有不同的调优方案。
4.3.5、建立索引要谨慎
建立数据库索引要谨慎尽量建立复合索引可以覆盖单个索引。
索引过多会影响查询速度这也就是我们上面所提到的树枝和叶子的问题索引就是树枝。
4.3.6、日期的处理
在期比较中尽可能不要用函数包裹字段避免失效。
将日期变成时间戳使用毫秒数进行比较如下图所示效果显而易见
4.4、数据库仓库与大数据有何关联
4.4.1、数据库
传统的关系型数据库的主要应用主要是基本的、日常的事务处理。 例如银行交易事务量较小增删改查量均等。
这类业务数据库大多是进行读写优化的对于偏重大量数据的读是支持不足的。
4.4.2、数据仓库
数据仓库的主要应用是 OLAPOn-Line Analytical Processing支持复杂的分析操作侧重决策支持并且提供直观易懂的查询结果。它的发展就如大数据的 Hive。
数据仓库的数据结构是为了分析和查询的便利。只读优化的数据库属于分析性数据库。 例如超市分析顾客群体的购物习惯进行活动针对促销只需要从购物者群里读数据和分析数据即可。
4.5、服务器架构演变解析
4.5.1、单节点
单节点 Web 服务器Web 中间件与数据库服务器在一台主机上。
优势成本低。 缺点服务器一出问题应用直接挂掉不支持高并发量大量数据的情况下造成硬盘 IO 开销过大。 演变优化分离单节点 Web 服务器。Web 服务器与数据库服务器各自在一台主机上。
4.5.2、分布式
多台 Web 服务器多台数据库服务器 。在服务中同时添加缓存。
注意对于内存池的配比要适当过大造成浪费过小无法支撑服务。 演变优化趋于多层分布式 在服务过程中添加代理服务器、缓存服务器等其他部件。
4.4.3、微服务
微服务即为“打乱分布式”在具体服务过程中添加代理服务器、注册中心、多个多种微服务服务器、接口。
服务关联注册中心根据不同请求去调用不同接口的功能同时添加第三方服务等。现在多为多点分布式比如我们熟知淘宝、京东。 备注gateway分发注册中心。
注意架构师要选择适合业务场景的架构。虽然微服务易于开发和维护但是成本比较高适合变化不大的需求场景资金雄厚的公司。因为可能某一个微服务端口出问题其他配套的上百个端口就需要二次运维保证、测试等成本很高。
五、新一代前后端分离
5.1、前后端分离知多少
MVVM——Model-View-ViewModelMVC——Model-View-Controller
View 层是视图Model 层是业务逻辑Controller 层用来调度 View 层和 Model 层ViewModel 和 Controller 可以理解为 Model 和 View 的处理器。 前后端分离的架构模式从我们熟知的 MVC 发展到 MVVM。MVC 中 Controller 演变成 MVVM 中的 viewModel。MVVM 主要解决了 MVC 中大量的 DOM 操作使页面渲染性能降低加载速度变慢影响用户体验。和当 Model 频繁发生变化开发者需要主动更新到 View 。
5.2、内容展示和业务逻辑的分离
最初的前后端分离就是我们下面所看到的前端负责页面负责发送请求。后端负责处理请求和响应。 5.3、前端业务和后端业务的分离
而现在绝大多数使用的前后端分离多为前台仅负责前台使用后端提供的统一的API调用数据进行显示即可。
后端处理好业务逻辑将数据封装好响应给前台即可。 5.3.1、优势
大大减轻了应用服务器压力。很多数据在前台就已经检验完成同时静态文件有专属的服务器无需多次请求应用服务器。后端将全部数据封装在对象中通过统一 API 给前台 URL和参数信息处理好逻辑从对应 DB 取数据即可。极大的提升了开发效率。
5.3.2、应用
现在大型企业开发多使用第二种模式。敏捷开发、快速迭代可能在业务刚谈好后端的数据逻辑就提前做好了只需要前端调用显示即可。
5.3.3、存在的挑战
两头的完美配合这就要求前端人员需要懂后端开发了解如何取后端的数据。
各行各业都是缺高手的既要求能够读懂整体业务又能做到分库分表。
5.4、越分越简单还是越复杂
对于前后端分离不同模式的选择要看不同的业务领域里面所考虑的因素是全面的。
对于企业和老板而言资金是挑战老板需要对产品线投入合理的资金。资金多多益善但是少了不能维持开发。 对于技术层面和架构师而言架构师要在技术权衡之后根据项目选择合适的模式。 总结 “滚滚长江东逝水,浪花淘尽英雄。”全栈学习若想达到炉火纯青的境地所投入成本是巨大的经验的积累和同化少则两三年多则数十年。Java 激荡三十年本文给大家从一开始 Java 的框架应用发展到后面的高阶架构解决方案和前后端分离从最基础的技术框架到分布式架构、服务器中间件、服务器技术、容器技术以及各种业务解决方案彻底的捋了一遍希望本文对初学者而言能够帮你开启你学习全栈的大门。待你学成归来给我留句言吧“吟咏流千古声名动四夷。” 我是白鹿一个不懈奋斗的程序猿。望本文能对你有所裨益欢迎大家的一键三连若有其他问题、建议或者补充可以留言在文章下方感谢大家的支持
