上次部署过了zookeeper，今天写写部署dubbo-admin dubbo-admin部署起来非常简单，只要会部署java程序就好。 本文已tomcat作为实例。 首先不多说，先下载相应的包。 本人网盘中有相应需要的包，方便下载。百度网盘 首先嘛。上传tomcat并解压。 上传dubbo-admin-2.4.1.war 包至tomcat下webapps 并启动tomcat(最好将war包先改名后再启动) 启动完成后： 进入ROOT/WEB-INF/目录，修改dubbo.properties文件 将上篇文章配置的三个zookeeper相关信息写入。然后重启tomcat 出现上图则表示部署成功！ 登录，进入系统
因公司电脑下班后关闭，重启虚拟机时发现zookeeper不能自动启动，所以再开文章记录一下，以备后用。 本文已center os 7示例： 首先进入/etc/rc.d/init.d/目录 cd /etc/rc.d/init.d/ 1 创建zookeeper文件并授权 touch zookeeper chmod +x zookeeper vi zookeeper 1 2 3 写入以下代码 #!/bin/bash #chkconfig:2345 20 90 #description:zookeeper #processname:zookeeper case $1 in start)…
声明：本文为笔者随心所写，随意而为。文中介绍仅作参考。出了啥问题本人不负责！ 先说说为啥写这东东吧,本人现已从业4年有余，工作以来也就是写写增删改查，调用/推出相应接口。感觉自身进入一个瓶颈了，所以就从网上找了下最近比较火的技术资料来看。 感觉相比大数据而言，学学分布式会相应简单一些。所以就开始学习dubbo了。 好了，不在废话了，开始进入正题吧。 首先呢。学dubbo嘛，就要先了解什么是分布式。 其实呢，分布式是一种很简单的概念。 说白了，就是拆程序。把一个整体的程序拆成大大小小的一块块，然后将他们分别部署到不同的机器上，然后通过一些网络协议将他们连接起来，为用户提供整套应用支持。 好了，说到这里也不多说了，一些基础理论啥的不是我的强项。说不来。 明白了分布式后，开始考虑如何把现有项目拆分，按什么模式拆分，中间用什么协议支撑。等等…… 在这个时候，朋友推荐了dubbo， 看了一些资料后，很感兴趣，所以开始研究。 开始正题！ 因个人项目原本就是Spring MVC+Mybaties架构的。 所以拆项目选择了dubbo+zookeeper+Spring MVC+Mybaties 首先，部署zookeeper。 第一步，准备三台linux机器（Windows也可以使用，本文不做介绍，本文使用的是VMware虚拟机）。 192.168.10.94 192.168.10.95 192.168.10.96 第二步，下载zookeeper包。(文章后会附有本人百度网盘地址。) 登录192.168.10.94 上传zookeeper包机器 解压(为方便输入，更改下文件夹名) 进入zook下conf文件夹 将zoo_sample.cfg改名为zoo.cfg 配置zoo.cfg [html] view…
rsync命令是一个远程数据同步工具，可通过LAN/WAN快速同步多台主机间的文件。rsync使用所谓的“rsync算法”来使本地和远程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。 rsync是一个功能非常强大的工具，其命令也有很多功能特色选项，我们下面就对它的选项一一进行分析说明。 语法 rsync [OPTION]... SRC DEST rsync [OPTION]... SRC [USER@]host:DEST rsync [OPTION]... [USER@]HOST:SRC DEST rsync [OPTION]... [USER@]HOST::SRC DEST rsync [OPTION]... SRC [USER@]HOST::DEST rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST] 对应于以上六种命令格式，rsync有六种不同的工作模式： 拷贝本地文件。当SRC和DES路径信息都不包含有单个冒号":"分隔符时就启动这种工作模式。如：rsync -a…
Cloud computing is traveling along the hype cycle quickly, cloud technologies are maturing, and cloud adoption is accelerating on a global scale. Most IT managers now agree that cloud computing…
1/ISAM ISAM是一个定义明确且历经时间考验的数据表格管理方法，它在设计之时就考虑到数据库被查询的次数要远大于更新的次数。因此，ISAM执行读取操作的速度很快，而且不占用大量的内存和存储资源。ISAM的两个主要不足之处在于，它不支持事务处理，也不能够容错：如果你的硬盘崩溃了，那么数据文件就无法恢复了。如果你正在把ISAM用在关键任务应用程序里，那就必须经常备份你所有的实时数据，通过其复制特性，MySQL能够支持这样的备份应用程序。 2/InnoDB 它提供了事务控制能力功能，它确保一组命令全部执行成功，或者当任何一个命令出现错误时所有命令的结果都被回退，可以想像在电子银行中事务控制能力是非常重要的。支持COMMIT、ROLLBACK和其他事务特性。最新版本的Mysql已经计划移除对BDB的支持，转而全力发展InnoDB。 MyIASM是IASM表的新版本，有如下扩展： 二进制层次的可移植性。 NULL列索引。 对变长行比ISAM表有更少的碎片。 支持大文件。 更好的索引压缩。 更好的键吗统计分布。 更好和更快的auto_increment处理。 以下是一些细节和具体实现的差别： 1.InnoDB不支持FULLTEXT类型的索引。 2.InnoDB中不保存表的 具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。 3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。 4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。 5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。 另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table…
MySql:charset和collation的设置 charset 和 collation 有多个级别的设置：服务器级、数据库级、表级、列级和连接级 www.2cto.com 1.服务器级 查看设置：show global variables like 'character_set_server'; 和 show global variables like 'collation_server'; 修改设置：在OPTION FILE （/etc/mysql/my.cnf）里设置： [mysqld] character_set_server=utf8 collation_server=utf8_general_ci 2. 数据库级 查看设置：select *…
作为创业公司和推行DevOps工程师们来说，都遇到过这样的问题： 硬件资源利用率的问题，造成部分成本的浪费 在网站功能中不同的业务场景有计算型的，有IO读写型的，有网络型，有内存型的，集中部署应用就会导致资源利用率不合理的问题。比如，一个机器上部署的服务都是内存密集型，那么CPU资源就都很容易浪费了。 单物理机多应用无法对无法进行有效的隔离，导致应用对资源的抢占和相互影响 一个物理机器跑多个应用，无法进行所使用的CPU，内存，进程进行限制，如果一个应用出现对资源的抢占问题，就会引起连锁反应，最终导致网站部分功能不可用。 环境、版本管理复杂，上线部署流程缺乏，增加问题排查的复杂度 由于内部开发流程的不规范，代码在测试或者上线过程中，对一些配置项和系统参数进行随意的调整，在发布时进行增量发布，一旦出现问题，就会导致测试的代码和线上运行的代码是不一致的，增加了服务上线的风险，也增加了线上服务故障排查的难度。 环境不稳定，迁移成本高，增加上线风险 在开发过程中存在多个项目并行开发和服务的依赖问题，由于环境和版本的复杂性很高，不能快速搭建和迁移一个环境，导致无法在测试环境中无法模拟出线上的流程进行测试，很多同学在线上环境进行测试，这里有很高的潜在风险，同时导致开发效率降低。 传统虚拟机和物理机占用空间大，启动慢，管理复杂等问题 传统虚拟机和物理机在启动过程进行加载内核，执行内核和init进行，导致在启动过程占用很长时间，而且在管理过程中会遇到各种各样的管理问题。 基于Docker容器技术，运维技术团队开发了五阿哥网站的容器云平台。通过容器云平台95%的应用服务已经实现容器化部署。这些应用支持业务按需拓展，秒级伸缩，提供与用户友好的交互过程，规范了测试和生产的发布流程，让开发和测试同学从基础的环境配置和发布解放出来，使其更聚焦自己的项目开发和测试。结合五阿哥容器云平台和Docker容器技术的实践，本文先介绍如何实现724小时“一站式”的持续交付，实现产品的上线。 *容器云平台架构图 Docker镜像标准化 众所周知，Docker的镜像是分层的。对镜像分层进行约定： 第一层是操作系统层，由CentOS/Alpine等基础镜像构成，安装一些通用的基础组件； 第二层是中间件层，根据不同的应用程序，安装它们运行时需要使用到的各种中间件和依赖软件包，如，Nginx、Tomcat等； 第三层是应用层，这层仅包含已经打好包的各应用程序代码。 Docker Image分层 经验总结：如何让自己的镜像变的更小，PUSH的更快？ Docker Image优化前后对比 Dockerfile构建应用镜像，在中间件层遇到一些需要安装的软件包时，尽可能的使用包管理工具（如yum）或以git clone方式下载源码包进行安装，目的是将软件包的copy和安装控制在同一层，软件部署成功后清除一些无用的rpm包或源码包，让基础镜像的尺寸更小。 Java应用镜像中并没有将JDK软件包打入镜像，将JDK部署在每台宿主上，在运行镜像时，通过挂载目录的方式将宿主机上的Java家目录挂载至容器指定目录下。因为它会把基础镜像撑得非常大。 在构建应用镜像时，Docker会对这两层进行缓存并直接使用，仅会重新创建代码出现变动的应用层，这样就提高了应用镜像的构建速度和构建成功后向镜像仓库推送的速度，从整体流程上提升了应用的部署效率。 容器的编排管理 编排工具的选型：…
【编者的话】这是系列博文中的第一篇，本文作者使用Spring Cloud和Docker构建微服务平台，文章的例子浅显易懂。 本系列博文主要向大家介绍如何使用Spring Cloud和Docker构建微服务平台。 什么是Spring Cloud？ Spring Cloud 是Pivotal提供的用于简化分布式系统构建的工具集。Spring Cloud引入了云平台连接器（Cloud Connector）和服务连接器（Service Connector）的概念。云平台连接器是一个接口，需要由云平台提供者进行实现，以便库中的其他模块可以与该云平台协同工作。（更多介绍，可以阅读InfoQ的报道。） 在Spring Cloud提供的解决方案中，你将会发现如下的内容： Configuration Service Discovery Service Circuit breakers Distributed sessions Spring Boot Spring Cloud最重要的一点是它可以和Spring Boot一起工作，Spring Boot可以帮助开发者更容易地创建基于Spring的应用程序和服务。 从Spring Boot项目名称中的Boot就可以看出来，Spring…
最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务架构。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的。 目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。 那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？ 以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。 Round 1：背景 Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的，比如：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。 Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。 小结：如果拿Dubbo与Netflix套件做对比，前者在国内影响力较大，后者在国外影响力较大，我认为在背景上可以打个平手；但是若要与Spring Cloud做对比，由于Spring Source的加入，在背书上，Spring Cloud略胜一筹。不过，英雄不问出处，在背景这一点上，不能作为选择框架的主要因素，当您一筹莫展的时候，可以作为参考依据。 Round 2：社区活跃度 我们选择一个开源框架，社区的活跃度是我们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会越来越完善，不然当我们碰到问题，就不得不自己解决。而对于团队来说，也就意味着我们不得不自己去维护框架的源码，这对于团队来说也将会是一个很大的负担。 下面看看这两个项目在github上的更新时间，下面截图自2016年7月30日： Dubbo ：https://github.com/dubbo 最后更新时间为：2016年5月6日 Spring Cloud ：https://github.com/spring-cloud 最后更新时间为：12分钟前…