Browsed by
标签:MySQL

代码,到底该如何分层,才能给人赏心悦目的感觉?

代码,到底该如何分层,才能给人赏心悦目的感觉?

閱讀本文約花費: 8 (分鐘) # 背景 说起应用分层,大部分人都会认为这个不是很简单嘛 就controller,service, mapper三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,controller做的逻辑比service还多,service往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。 的确在这些人眼中分层只是一个形式,前辈们的代码这么写的,其他项目代码这么写的,那么我也这么跟着写。但是在真正的团队开发中每个人的习惯都不同,写出来的代码必然带着自己的标签,有的人习惯controller写大量的业务逻辑,有的人习惯在service中之间调用远程服务,这样就导致了每个人的开发代码风格完全不同,后续其他人修改的时候,一看,我靠这个人写的代码和我平常的习惯完全不同,修改的时候到底是按着自己以前的习惯改,还是跟着前辈们走,这又是个艰难的选择,选择一旦有偏差,你的后辈又维护你的代码的时候,恐怕就要骂人了。 所以一个好的应用分层需要具备以下几点: 方便后续代码进行维护扩展; 分层的效果需要让整个团队都接受; 各个层职责边界清晰。 # 如何进行分层 1、阿里规范 在阿里的编码规范中约束的分层如下: 开放接口层:可直接封装 Service 方法暴露成 …

Read More Read More

推荐的五款市面上常用的免费CMS建站系统

推荐的五款市面上常用的免费CMS建站系统

閱讀本文約花費: 11 (分鐘) 小乔做设计也有不少年头了,很多客户或者朋友找我做网站的时候,一般问我的是用什么软件系统给他们做。大部分客户希望用的软件是免费的。 所以今天小乔给大家介绍五款我自己用过还不错的,重点是还免费的建站系统。 MetInfo MetInfo这个系统是一个客户指定的,让我必须用这个系统给他做网站。于是我花了一些时间去了解这个系统。整个系统可操作性还是可以的。 MetInfo的框架是基于PHP+Mysql开发的。 从界面上来说,界面简洁一目了然,比较符合现在的用户习惯,扁平化的设计还是比较吸引用户的。从功能上来说,MetInfo功能基本齐全,常用的内容管理、多语言等基本功能都配备了。从使用上来说,一些版块的设计不是很人性化,藏得比较深,所以在使用的过程中会经常找不到,比较花时间。不过熟悉之后就好很多了。整体来说相对让我觉得系统比较出色的应该就是SEO这块,可设置的内容还是比较多的,seo效果也比较明显。总的来说,简单的界面设计还是很适合新手的。 主要的缺点就是技术服务跟不上,打400电话一直占线,qq上的技术服务又一直排队,问完一个问题再问一个qq技术服务直接没有响应。再来,小编没用过MetInfo的收费版,很多收费用户反映升级还要单独收费,这个收费标准可能还是存在一定的问题。 框架:PHP+Mysql架构 功能:会员、安全、营销、SEO、内容、移动端、多语言…

Read More Read More

第九章 Nacos Config–服务配置

第九章 Nacos Config–服务配置

閱讀本文約花費: 8 (分鐘) 本文介绍微服务架构下关于配置文件的一些问题,Nacos Config入门及深入,nacos的几个概念等,更多请看下文。 9.1 服务配置中心介绍 首先我们来看一下,微服务架构下关于配置文件的一些问题: 配置文件相对分散。在一个微服务架构下,配置文件会随着微服务的增多变的越来越多,而且分散在各个微服务中,不好统一配置和管理。 配置文件无法区分环境。微服务项目可能会有多个环境,例如:测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的,一旦需要修改,就需要我们去各个微服务下手动 维护,这比较困难。 配置文件无法实时更新。我们修改了配置文件之后,必须重新启动微服务才能使配置生效,这对一 个正在运行的项目来说是非常不友好的。 基于上面这些问题,我们就需要配置中心的加入来解决这些问题。 配置中心的思路是: 首先把项目中各种配置全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。 当各个服务需要获取配置的时候,就来配置中心的接口拉取自己的配置。 当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新。 当加入了服务配置中心之后,我们的系统架构图会变成下面这样: 在业界常见的服务配置中心,有下面这些: Apollo Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,…

Read More Read More

第七章 Rocketmq–消息驱动

第七章 Rocketmq–消息驱动

閱讀本文約花費: 16 (分鐘) 接上文,本文主要介绍了MQ是什么,及它的应用场景,消息发送和接收演示以及相关的案例。 7.1 MQ简介 7.1.1 什么是MQ MQ(Message Queue) 是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功。传统的做法如下: 此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。 所以实际当数据写入注册系统后,注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果,由消息队列 MQ 异步地进行这些操作。架构图如下: 异步解耦是消息队列 MQ 的主要特点,主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时,由于使用了消息队列MQ,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦合。 7.1.2.2 流量削峰 流量削峰也是消息队列 MQ 的常用场景,一般在秒杀或团队抢购(高并发)活动中使用广泛。…

Read More Read More

第六章 Sleuth–链路追踪

第六章 Sleuth–链路追踪

閱讀本文約花費: 11 (分鐘) 本文介绍微服务架构中最重要的设计模式:微服务之间的数据通讯。更多请看全文。 6.1 链路追踪介绍 在大型系统的微服务化构建中,一个系统被拆分成了许多模块。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种架构中,一次请求往往需要涉及到多个服务。 互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心,也就意味着这种架构形式也会存在一些问题 于是就出现了下面几个 问题 如何快速发现问题? 如何判断故障影响范围? 如何梳理服务依赖以及依赖的合理性? 如何分析链路性能问题以及实时容量规划? 分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪 台机器上、每个服务节点的请求状态等等。 常见的链路追踪技术有下面这些: cat 由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。 集成方案是通过代码埋点的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。 zipkin 由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时…

Read More Read More

第二章 微服务环境搭建

第二章 微服务环境搭建

閱讀本文約花費: 5 (分鐘) 本次是使用的电商项目中的商品、订单、用户为案例进行讲解。本章只是搭建基本环境,并不过多讲解. 2.1 案例准备 2.1.1 技术选型 maven:3.6.0 数据库:MySQL 5.7 持久层: SpingData Jpa 其他: SpringCloud Alibaba 技术栈 2.1.2 模块设计 下面是项目端口号说明及项目结构 springcloud-alibaba 父工程 shop-common公共模块【实体类】 shop-user用户微服务 【端口: 807x】 shop-product商品微服务 【端口: 808x】 shop-order订单微服务 【端口: 809x】 2.1.3 微服务调用 在微服务架构中,最常见的场景就是微服务之间的相互调用。我们以电商系统中常见的用户下单为例来演示微服务的调用:客户向订单微服务发起一个下单的请求,在进行保存订单之前需要调用商品微服务查询商品的信息。 我们一般把服务的主动调用方称为服务消费者,把服务的被调用方称为服务提供者。 在这种场景下,订单微服务就是一个服务消费者, 商品微服务就是一个服务提供者。 2.2 创建父工程 创建一个maven工程,然后在pom.xml文件中添加下面内容 截自 2020 年 1月 7日 版本对应: 2.3 创建基础模块 1 创建shop-common 模块,在pom.xml…

Read More Read More

AWS Solution Architecture Associate 认证攻略

AWS Solution Architecture Associate 认证攻略

閱讀本文約花費: 55 (分鐘) AWS认证介绍 AWS Certified Solutions Architect 系列认证是亚马逊从2013年开始推出的对云计算架构师能力的官方认证。考试不仅考察应试者对AWS相关云服务的熟悉程度,题目也多来源于实际中要解决的问题,要求应试者有全面的架构设计经验和积累,所以含金量很高。在美国招聘网站glassdoor上,AWS solution architect的身价平均在10万美金以上,可见业界对这个认证的认可程度。 它在国内的认可程度如何呢?根据我和考试认证中心的工作人员聊天打听到,国内来考试的分两类人,一类是工作单位和亚马逊有合作关系,单位出钱要求通过。另一类是云计算这个行业的早起的鸟儿,他们想充实自己的职业技能,在云计算这个浪潮中能有一席之地。所以相对来说了解和报考的人还是少数。 不过想顺利通过这个考试并不容易。一方面考试全程英文阅读量大。另一方面复习资料缺乏,只能通过官方的FAQ文档和白皮书进行学习,自学效率非常低。对于初次接触AWS云服务认证的同学来说,不花2,3个月的时间认证准备,是很难通过的。就算作者身边那些有2,3年AWS云服务使用经验的架构师,想裸考通过,成功率也几乎为零。所以,打算通过这个考试,一定要认真对待,规划好时间充分准备。 关于AWS认证考试更多的介绍,大家还可以参考网上刘涛同学的文章http://www.csdn…

Read More Read More

5分钟,告诉你Mysql字符串怎么做索引

5分钟,告诉你Mysql字符串怎么做索引

閱讀本文約花費: 4 (分鐘) 很多程序员都不喜欢字符串,我也是,字符串处理起来太麻烦了,而且字符串也比较占空间。举个例子,一个字符要占1个字节,但一般常用字符就那么几个(例如我们常要求用户名只能是大小写字母与数字)。另外一个问题,就是数据库查询的时候,用字符串查询太不方便了。今天我们来了解下,数据库中的字符串查询问题。 在PC互联网时代,我们的很多账户都需要绑定电子邮箱,我们偶尔需要使用电子邮箱,也就是字符串来进行数据查询,为了保证查询效率,我们通常要对字符串字段建立索引。 我们都知道,在InnoDB中,通常使用的是B+树索引,如果索引的类型是字符串,那么我们可能会面临这样一个问题,索引的长度会变得特别长,索引的长度过长会让索引的索引占用更多的存储空间,同时也会增加索引的维护成本。通常我们使用字符串索引,只会使用前面若干个字符,假如用户的邮箱的开头是26个字母,并且用户名随机均匀分布的,那么我们即使使用第一个字符做索引,也能减少25/26的扫描量,假如使用前2个字符,就可以减少675/676次扫描。所以,即便我们只用前面的若干个字符,也能大大地减少数据库的扫描,提升查询速度。 但是在现实生活中,用户名往往不是随机分布的,像a开头的用户往往占比较大。有些字符串的字段,往往开头是相似的,例如居民的身份证好,前面几位数通常是省份跟城镇,教育局的学生信息,通常id是入学时间加月份,索引的…

Read More Read More

CSRF的几种防御方法的利弊分析

CSRF的几种防御方法的利弊分析

閱讀本文約花費: 5 (分鐘) 本文直接从防御方式开始讨论,防御CSRF有4种方法: 使用POST替代GET检验HTTP Referer验证码Token 使用POST替代GET 一些程序员在开发的时候都是用GET、POST通用的函数来接收客户端的数据,这样也是某些接口有CSRF的原因之一,但是将全部接口都改成只允许POST方式访问,就能防范CSRF了吗?答案是:不能。只能说提高了一些成本。 原本是GET方式访问的接口,攻击者只需要构造接口的URL参数让受害者点击即可。现在改成使用POST方式访问,攻击者只需要利用其他站点,在站点上布置一个POST请求,让用户点击。 检验HTTP Referer HTTP Referer真是一个用于安全的字段,除了能防范CSRF,还能防JSONP劫持、盗链、站外提交等安全问题。但是HTTP Referer就一点问题都没有了吗?答案是:否定的,HTTP Referer只能检查点击的链接来源是来自站内还是站外,如果是GET方式的CSRF,那链接本身就是站内的,也就意味着检验HTTP Referer是无效的。 验证码 上面说的两种防御CSRF的方式,都有一定缺陷。但是使用验证码是完全可以做到防止CSRF的,因为验证码是用户在提交表单的时候,必须输入图片验证码,保证了服务器收到的是来自预期的请求。这里我补充一下,验证码功能必须没有缺陷才行,我之前测试过很多W…

Read More Read More

如何成为优秀的技术主管?你要做到这三点

如何成为优秀的技术主管?你要做到这三点

閱讀本文約花費: 36 (分鐘) 技术主管,又叫「技术经理」,英文一般是 Tech Leader ,简称 TL。随着工作经验的不断积累,能力的不断提升,每个人都有机会成为Team Leader。然而在机会到来前,我们必须提前做好准备,对TL的工作职责有一定了解。当然,这也会为当下更好地配合TL工作打下基础。 今天, 结合自己多年的经验,从开发规范、开发流程、技术规划与管理三个角度出发,分享对技术TL这一角色的理解与思考。 「技术主管」是开发团队中的某位程序员需要对一起创建系统的整个开发团队负责时所承担的角色。通常他既要对最终交付的软件系统负责,另外也会像一个程序员一样去开发实现系统。 一个技术主管的 60% ~ 70% 的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上,而余下的 30% ~ 40% 的时间则花在为了保障系统按时交付所需的各种计划、协作、沟通、管理上。和团队管理者不同的是,技术主管的大部分管理工作都是针对具体研发任务和技术事务的。 接下来基于我在技术TL这个角色上,在开发规范、开发流程、技术管理与规划等方面我的一些心路历程,和大家共勉。 开发规范 我当时负责的业务是集团收购一家子公司的业务,在整体技术标规范上与集团的技术标准存在很大的差异。开发规范可以说是我来到这个团队干的第一件事,我当时面对的问题是API接口格式混乱,没有标准的RPC服…

Read More Read More