后端技术

1、引言 关于“负载均衡”的解释，百度词条里：负载均衡，英文叫Load Balance，意思就是将请求或者数据分摊到多个操作单元上进行执行，共同完成工作任务。 负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。 负载均衡有两方面的含义： 1）首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间； 2）其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。 简单来说就是： 1）其一是将大量的并发处理转发给后端多个节点处理，减少工作响应时间； 2）其二是将单个繁重的工作转发给后端多个节点处理，处理完再返回给负载均衡中心，再返回给用户。 目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。 总之，它的目的就通过调度集群，达到最佳化资源使用，最大化吞吐率，最小化响应时间，避免单点过载的问题。 内容概述：本文将从负载均衡技术的分类、技术原理、常见实现算法、常用方案等入手，为您详细讲解负载均衡技术的方方面面。这其中，四层和七层负载均衡技术最为常用，它们也是本文介绍的重点。 内容点评

前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。 核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。 在互联网架构中，名词解释： Web服务器：一般指像nginx，apache这类的服务器，他们一般只能解析静态资源。 应用服务器：一般指像tomcat，jetty，resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好。 一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。 一、开发人员分离 以前的JavaWeb项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。 随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。 大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，小编建议是分开。 1.对于后端Java工程师： 把精力放在Java基础，设计模式

模块化设计 根据业务场景，将业务抽离成独立模块，对外通过接口提供服务，减少系统复杂度和耦合度，实现可复用，易维护，易拓展 项目中实践例子： Before： 在返还购APP里有个【我的红包】的功能，用户的红包数据来自多个业务，如：邀请新用户注册领取100元红包，大促活动双倍红包，等各种活动红包，多个活动业务都实现了一套不同规则的红包领取和红包奖励发放的机制，导致红包不可管理，不能复用，难维护难拓展 After： 重构红包业务 红包可后台管理 红包信息管理，可添加，可编辑，可配置红包使用的规则，可管理用户红包 红包奖励发放统一处理 应用业务的接入只需要专注给用户进行红包发放即可 设计概要 Before VS After 产品有时提出的业务需求没有往这方面去考虑，结合场景和未来拓展需要，在需求讨论的时候提出模块化设计方案，并可以协助产品进行设计 通用服务抽离 在项目开发中经常会遇到些类似的功能，但是不同的开发人员都各自实现，或者因为不能复用又重新开发一个，导致了类似功能的重复开发，所以我们需要对能够抽离独立服务的功能进行抽离，达到复用的效果，并且可以不断拓展完善，节约了后续开发成本，提高开发效率，易于维护和拓展 项目中实践例子： Before 在业务中经常需要对用户进行信息通知，如：短信定时通知，APP消息推送，微信通知，等 开发人员在接到需求中有通知功能的时候没有考虑后续拓展

静态HTML指：使用单纯的HTML或者结合CSS制作的包括图片、文字等的只供用户浏览但不包含任何脚本、不含有任何交互功能的网页。 动态的HTML指：网页不仅提供给用户浏览，网页本身还有交互功能，存在着在脚本如JAVASCRIPT，并利用某种 服务器端 语言如PHP等实现如用户注册， 用户登录 ，上传文件，下载文件等功能，动态页面可以人机互动，静态只能回服务器的数据库再回到页面 后端渲染（SSR、服务端渲染） 后端渲染HTML的情况下，浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串，这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的，在这种情况下，浏览器只进行了HTML的解析，以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。 前后端不分离，一般情况下前端只需要根据设计完成页面就可以，数据可以暂时使用静态数据，包括图片、文字等。页面写完就可以交给后端同事了，他们引入你写的样式，将页面和数据进行渲染再返回到浏览器！ 前端渲染（SPA、单页面应用） 前端渲染就是指浏览器会从后端得到一些信息，这些信息或许是适用于题主所说的angularjs的模板文件，亦或是JSON等各种数据交换格式所包装的数据，甚至是直接的合法的HTML字符串。这些形式都不重要，重要的是

title: GamePM项目总结 date: 2019-12-09 21:07:50 tags: cnbolgsWork --- GamePM项目总结 自从开题选定GamePM这个项目以来，我们选定了小型社群赛事管理作为功能核心。经过近一个学期的努力，我认为我们的GamePM项目不完美结题了。 GitHub 设计存放和前后端对接 GitHub 前端代码 GitHub 后端代码 最终页面 pj.tenderkun.com 前期设计 在前期，我作为团队中唯一拥有编写类似软件经验的人担任组长设计了我们小组这个课题的技术栈。我选择后端使用spring boot使用spring cloud中的spring session鉴权，前端使用react+antd。同时使用分布式的后端在spring session的帮助下我们能不受限制的分工开发后端。选定这两端的技术的理由主要是这是目前前后端比较火热的选择，各种教程完善，就算是组员没有相关经验java和类似java的js能够让他们快速上手。 但是在分工部分我的决定开始有失误。我想当然的认为前端的工作比较繁琐但是非常简单，而我们赛事管理的各种赛事的算法需要我来着眼。但是我没有和我的组员组队编程的经验，我以前的开发时间安排并不适合我的组员，react作为新兴的前端框架功能强大，但是显然不如原生html+js或者古老的jquery更简单

软件工程个人总结 一、引言 1.1 项目介绍——社团管理系统 1.1.1 项目背景 在当代大学生的日常生活中，社团是必不可少的一个部分。如果仅仅是通过纸质文档进行管理的话，不但需要耗费大量的人力和资源，也会给管理造成不便。为了提升社团组织者对社团管理的便利性，我们小组选择社团管理这一主题，开发一款便于社团管理的系统。 1.1.2 系统简介 社团管理系统的操作角色分为游客、学生、管理员三种类型，集成了社团浏览、活动浏览、社团申请、活动创建、活动审批、入社申请审批、社团内部事务管理等功能模块，为社团管理者与学生提供一个方便的数字化管理平台。 1.2 相关文档汇总 社团管理系统需求分析 社团管理系统设计图 社团管理系统原型阶段 社团管理系统接口文档 github前后端代码 二、项目制作过程——个人分工 2.1 起步 2.1.1 需求分析 参与组内讨论，根据学生、普通社员、社长、管理员4种角色来提出需求 2.1.2 墨刀原型 两项简易墨刀原型 web端原型 app端原型 2.2 设计图 详见 设计图文档 2.2.1 用例图 全部用例图 2.2.2 顺序图 仅参与确认 2.2.3 类图 整个类图的绘制与类图说明 2.3 技术选型 2.3.1 查阅与学习 由于组内成员没有相关项目开发经验，如前端框架、路由、接口信息接受发送，后端框架、信息接受与发送。因此学习、试错花费大量时间。 查找资料

1. 全栈工程师之路-Node.js 高可用架构专用 原文[高可用架构] https://mp.weixin.qq.com/s?_ biz=MzAwMDU1MTE1OQ==&mid=405001493&idx=1&sn=f0ecab9b31bad83fb065ac37bb728245&scene=1&srcid=0324iTRH12WbXL5VDxXnEhH8&key=710a5d99946419d938a0ffc16a3c72118eefbe33f3f8312ed218bccbde126b60e818c8eb1068a9b07bdc8116a077b911&ascene=0&uin=NDIzMjM3MDk1&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.5+build(14F27)&version=11000006&pass ticket=xdp3crkTJPuOH6ggUMKnwvfDGKEnMUvwC5V%2FdxlW%2FKdNO9R8zI1xsDFSR4ZJECUU 仔细的对比了一遍，感谢tim yang和庆丰校长的整理，非常严谨，比我讲的要好，另外感谢霍老板封我是StuQ明星讲师[呲牙][呲牙] 1.1. 主要内容 Why Node.js ？ 历史 槽点 架构平衡和选择 企业级 我眼中的Node.js核心 快速开发实践

全栈工程师之路-Node.js 高可用架构专用 原文[高可用架构] https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=405001493&idx=1&sn=f0ecab9b31bad83fb065ac37bb728245&scene=1&srcid=0324iTRH12WbXL5VDxXnEhH8&key=710a5d99946419d938a0ffc16a3c72118eefbe33f3f8312ed218bccbde126b60e818c8eb1068a9b07bdc8116a077b911&ascene=0&uin=NDIzMjM3MDk1&devicetype=iMac+MacBookPro11%2C1+OSX+OSX+10.10.5+build(14F27)&version=11000006&pass_ticket=xdp3crkTJPuOH6ggUMKnwvfDGKEnMUvwC5V%2FdxlW%2FKdNO9R8zI1xsDFSR4ZJECUU 仔细的对比了一遍，感谢tim yang和庆丰校长的整理，非常严谨，比我讲的要好，另外感谢霍老板封我是StuQ明星讲师[呲牙][呲牙] 持续更新版本 仓库地址 https://github.com/i5ting/nodejs-fullstack 在线阅读 http:/

看看前端圈子里，各种技术、理论，在这两年烈火烹油，花了众人眼。前端似乎这也能做，那也能搞，但是到底何为前端呢？ 个人定义：前端，就是浏览器端。不管前端怎样发展，一定是比后端简单的，因为前端几乎只用关心业务本身，后端则在关心业务的同时，还要关心开发环境本身的逻辑。这种关心是硬性的，也就是你如果不关心，完全无法开始开发工作。 回到最初始状态：前端，随便新建一个记事本，写几句代码，重命名成html后缀，双击就能看效果。后端，就为了一个“hello world!"，不论是php，还是jsp，都要安装服务器，sdk，还要各种环境变量配置。写一个前端的应用，你只要理清你的业务逻辑，熟悉你的语言工具就行，不用担心环境，环境就是浏览器，最多就是ajax，cookie，再装一个服务器，不停点击确定，安装了就可以用了。后端还要理清开发环境本身的运行配置逻辑，不然，每次配环境都百度，出了问题到处"跪求"。 后端的复杂性当然不只是配个环境而已，前端的所谓"简单"当然也是相对而言的，任何一门手艺，想要用它吃饭，再用它过上好的生活都是不简单的，一个牛逼的程序员在自己的圈子里也许还是"最好的厨师"，“ps高手”，“深度xx发烧友”，但是你真正进入厨师的圈子，进去其他那些看似简单，自己一学就会的圈子，就知道自己的渺小和低端了 可能是js的缘故，很多人把nodejs也算在前端，自己感觉显然不是。最基本的

nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器，而且nginx还可以按照调度规则实现动态、静态页面的分离，可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡，同时还支持后端服务器的健康检查。 如果只有一台服务器时,这个服务器挂了,那么对于网站来说是个灾难.因此，这时候的负载均衡就会大显身手了,它会自动剔除挂掉的服务器. 下面简单的介绍下我使用Nginx做负载的体会 Nginx负载均衡一些基础知识: nginx 的 upstream目前支持 4 种方式的分配 1)、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 2)、weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 3)、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 4)、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。 5)、url_hash（第三方） 配置： 在http节点里添加: #定义负载均衡设备的 Ip及设备状态 upstream myServer { server 127.0.0.1:9090 down; server 127.0.0.1:8080 weight=2; server