A box of chocolates

Life is like a box of chocolates, you never know what you are going to get.

Uncategorized

Centos7 初始化硬盘分区、挂载

Vinny Wang 0 Comments

https://www.cnblogs.com/stulzq/p/7610100.html 刚刚在腾讯云买了一台服务器，刚买的服务器的数据盘都是需要自己来分区的，下面就记录一下操作。 通过命令fdisk-l查看硬盘信息 可以看到有两块硬盘/dev/vda和/dev/vdb，启动vda是系统盘vdb是我们新增的数据盘。 2.执行以下命令，进入fdisk模式，开始对新增数据盘执行分区操作。 fdisk 新增数据盘 以新挂载的数据盘“/dev/xvdb”为例： fdisk /dev/xvdb 回显类似如下信息： 3.输入“n”，按“Enter”，开始新建分区。 回显类似如下信息： 表示磁盘有两种分区类型： “p”表示主要分区。 “e”表示延伸分区。 4.以创建一个主要分区为例，输入“p”，按“Enter”，开始创建一个主分区。 回显类似如下信息： “Partition number”表示主分区编号，可以选择1-4。 5.以分区编号选择“1”为例，输入主分区编号“1”，按“Enter”。 回显类似如下信息 “First sector”表示初始磁柱区域，可以选择2048-20971519，默认为2048。 6.以选择默认初始磁柱编号2048为例，按“Enter”。 回显类似如下信息： “Last sector”表示截止磁柱区域，可以选择2048-104857599，默认为104857599。 7.以选择默认截止磁柱编号2104857599为例，按“Enter”。 回显类似如下信息：…

Uncategorized

CentOS7与CentOS6区别

Vinny Wang 0 Comments

本人之前使用的Linux是虚拟机上的CentOS6.X作为服务器环境，后来要发布线上项目，就购买了云服务器，阿里服务器的云翼计划学生购买只有CentOS7.3可以选择，抱着趁此机会学习CentOS新版本的更多特性的心态，毅然选择了购买使用，果然不出所料呀，踩了不少雷，当然也就学习了更多新知识，下面就分析一下CentOS7.X与CentOS6.X的区别以及注意点，希望可以帮助到小伙伴，大神可以略过，请轻虐。 CentOS7与CentOS6的区别图 命令 centos6 centos7 备注 ifconfig 有 有 yum install -y net-tools rouet 有 有 yum install -y net-tools ntpd服务和ntpdate命令 有 有 yum install ntp ntpdate cat /etc/issue 有版本号…

Uncategorized

MySQL慢查询日志总结

Vinny Wang 0 Comments

慢查询日志概念 MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time值的SQL，则会被记录到慢查询日志中。long_query_time的默认值为10，意思是运行10S以上的语句。默认情况下，Mysql数据库并不启动慢查询日志，需要我们手动来设置这个参数，当然，如果不是调优需要的话，一般不建议启动该参数，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表。 慢查询日志相关参数 MySQL 慢查询的相关参数解释：slow_query_log ：是否开启慢查询日志，1表示开启，0表示关闭。 1 2 3 4 5 6 slow_query_log ：是否开启慢查询日志，1表示开启，0表示关闭。 log-slow-queries ：旧版（5.6以下版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺省的文件host_name-slow.log slow-query-log-file：新版（5.6及以上版本）MySQL数据库慢查询日志存储路径。可以不设置该参数，系统则会默认给一个缺省的文件host_name-slow.log long_query_time ：慢查询阈值，当查询时间多于设定的阈值时，记录日志。 log_queries_not_using_indexes：未使用索引的查询也被记录到慢查询日志中（可选项）。 log_output：日志存储方式。log_output='FILE'表示将日志存入文件，默认值是'FILE'。log_output='TABLE'表示将日志存入数据库，这样日志信息就会被写入到mysql.slow_log表中。MySQL数据<br>库支持同时两种日志存储方式，配置的时候以逗号隔开即可，如：log_output='FILE,TABLE'。日志记录到系统的专用日志表中，要比记录到文件耗费更多的系统资源，因此对于需要启用慢查询日志，又需<br>要能够获得更高的系统性能，那么建议优先记录到文件。 慢查询日志配置 默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的，可以通过设置slow_query_log的值来开启，如下所示： 1 2 3 4 5 6 7…

Uncategorized

nginx配置location总结及rewrite规则写法

Vinny Wang 0 Comments

语法规则： location /uri/ { … } = 开头表示精确匹配 ^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。 ~ 开头表示区分大小写的正则匹配 ~* 开头表示不区分大小写的正则匹配 !~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则 / 通用匹配，任何请求都会匹配到。 多个location配置的情况下匹配顺序为（参考资料而来，还未实际验证，试试就知道了，不必拘泥，仅供参考）: 首先匹配 =，其次匹配^~, 其次是按文件中顺序的正则匹配，最后是交给 / 通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。 例子，有如下匹配规则： location =…

Uncategorized

Windows 入侵类问题排查思路

Vinny Wang 0 Comments

深入分析，查找入侵原因 一. 检查帐户和弱口令 查看服务器已有系统或应用帐户是否存在弱口令。 检查说明：主要检查系统管理员帐户、网站后台帐户、数据库帐户以及其他应用程序（FTP、Tomcao、phpMyAdmin 等）帐户是否存在弱口令。 检查方法：根据实际情况自行确认。 风险性：高 查看下服务器内是否有非系统和用户本身创建的账户。 检查说明：一般黑客创建的异常账户账户名会在本地用户组显示出来。 检查方法：打开 cmd 窗口，输入lusrmgr.msc命令，查看是否有新增的账号，如有管理员群组的（Administrators）里的新增账户，如有，请立即禁用或删除掉。 风险性：高 检查是否存在隐藏账户名 检查说明：黑客为了逃避检查，往往会在您服务器内创建隐藏用户，隐藏账户在本地用户内是查看不到的。 检查方法（您也可以通过下载 LD_check 安全工具检查是否有隐藏账户）： 在桌面打开运行（可使用快捷键 Win + R），输入 regedit，即可打开注册表编辑器； 选择 HKEY_LOCAL_MACHINE/SAM/SAM，默认无法查看该选项内容，右键菜单选择权限，打开权限管理窗口； 选择当前用户（一般为 administrator），将权限勾选为完全控制，然后确定，关闭注册表编辑器； 再次打开注册表编辑器，即可选择 HKEY_LOCAL_MACHINE/SAM/SAM/Domains/Account/Users；…

Uncategorized

Linux 入侵类问题排查思路

Vinny Wang 0 Comments

深入分析，查找入侵原因 一、检查隐藏账户及弱口令 检查服务器系统及应用账户是否存在 弱口令： 检查说明：检查管理员账户、数据库账户、MySQL 账户、tomcat 账户、网站后台管理员账户等密码设置是否较为简单，简单的密码很容易被黑客破解。 解决方法：以管理员权限登录系统或应用程序后台，修改为复杂的密码。 风险性：高 使用last命令查看下服务器近期登录的账户记录，确认是否有可疑 IP 登录过机器： 检查说明：攻击者或者恶意软件往往会往系统中注入隐藏的系统账户实施提权或其他破坏性的攻击。 解决方法：检查发现有可疑用户时，可使用命令usermod -L 用户名禁用用户或者使用命令userdel -r 用户名删除用户。 风险性：高 通过less /var/log/secure|grep 'Accepted'命令，查看是否有可疑 IP 登录机器成功： 检查说明：攻击者或者恶意软件往往会往系统中注入隐藏的系统账户实施提权或其他破坏性的攻击。 解决方法： 使用命令usermod -L 用户名禁用用户或者使用命令userdel -r…

Uncategorized

微服务架构初探

Vinny Wang 0 Comments

https://xiaoxubeii.github.io/articles/microservices-architecture-introduction/ 什么是微服务 首先微服务并没有一个官方的定义，想要直接描述微服务比较困难，我们可以通过对比传统WEB应用，来理解什么是微服务。 传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下： 尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。 这种单体应用比较适合于小项目，优点是： 开发简单直接，集中式管理 基本不会重复开发 功能都在本地，没有分布式的管理开销和调用开销 当然它的缺点也十分明显，特别对于互联网公司来说： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 代码维护难：代码功能耦合在一起，新人不知道何从下手 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 扩展性不够：无法满足高并发情况下的业务需求 所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。 比如，前面描述的系统可被分解为： 每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。 微服务架构的优点 微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。 其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。 第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。 最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。 微服务架构的缺点和挑战 实际上并不存在silver bullets，微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似，微服务强调了服务大小，但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。 微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。…

Uncategorized

一篇文章快速理解微服务架构

Vinny Wang 0 Comments

http://www.dockone.io/article/3687 什么是微服务 首先微服务并没有一个官方的定义，想要直接描述微服务比较困难，我们可以通过对比传统WEB应用，来理解什么是微服务。 传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下： 尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。 这种单体应用比较适合于小项目，优点是： 开发简单直接，集中式管理 基本不会重复开发 功能都在本地，没有分布式的管理开销和调用开销 当然它的缺点也十分明显，特别对于互联网公司来说： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 代码维护难：代码功能耦合在一起，新人不知道何从下手 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 扩展性不够：无法满足高并发情况下的业务需求 所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。 比如，前面描述的系统可被分解为： 每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。 微服务架构的优点 微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。 其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。 第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。 最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。 微服务架构的缺点和挑战 实际上并不存在silver bullets，微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似，微服务强调了服务大小，但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。 微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。…

« Previous Page — Next Page »

You Missed

Uncategorized

html:table属性以及html简单合并单元格应用

Uncategorized

处理nginx启动错误Failed to read PID from file /run/nginx.pid

Uncategorized

Systemd 入门教程：命令篇

Uncategorized

Centos安装supervisor，守护Redis进程