March 2018

http://microservices.io/patterns/microservices.html Context You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, […]

https://yq.aliyun.com/articles/8611 摘要： 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》在InfoQ上的一个分 概述 关于微服务的介绍，可以参考微服务那点事。 微服务是最近非常火热的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》（是Design RESTful API的作者）在InfoQ上的一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway’s Law）。 在康威的这篇文章中，最有名的一句话就是： Organizations which design systems are constrained to

https://yq.aliyun.com/articles/2764 摘要： 微服务架构被提出很短的时间内，就被越来越多的开发人员推崇，简单来说其主要的目的是有效的拆分应用，实现敏捷开发和部署 。本分享即尝试介绍微服务架构的一些实施细节和要求，探询微服务架构的由来，并最终提供我们团队内部的一些实践总结，希望对大家有帮助。 WHAT – 什么是微服务 微服务简介 这次参加JavaOne2015最大的困难就是听Microservice相关的session，无论内容多么水，只要题目带microservice，必定报不上名，可见Microservice有多火。最喜欢其中一页。关于这个典故，可以参考[this]( http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-not-think-it-means-what-you-think-it-means)，此图适用于一切高大上的名字——技术有SOA，Agile，CLOUD，DevOps等等，古代有道，气，八卦等等。此类名词的最大特点就是 一解释就懂，一问就不知，一讨论就打架。 微服务的流行，Martin功不可没，这老头也是个奇人，特别擅长抽象归纳和制造概念，我觉的这就是最牛逼的markting啊，感觉这也是目前国人欠缺的能力。 Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家.福勒（Martin Fowler），在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍：《企业应用架构模式》、《UML精粹》和《重构》等。—— 百度百科 先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（比较难传神的翻译）。所有的功能打包在一个WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了DO/DAO，Service，UI等所有逻辑。 Monolithic比较适合小项目，优点是： 开发简单直接，集中式管理

你是不是经常需要 SSH 或者 telent 远程登录到 Linux 服务器？你是不是经常为一些长时间运行的任务而头疼，比如系统备份、ftp 传输等等。通常情况下我们都是为每一个这样的任务开一个远程终端窗口，因为他们执行的时间太长了。必须等待它执行完毕，在此期间可不能关掉窗口或者断开连接，否则这个任务就会被杀掉，一切半途而废了。 元凶：SIGHUP 信号 让我们来看看为什么关掉窗口/断开连接会使得正在运行的程序死掉。 在Linux/Unix中，有这样几个概念： 进程组（process group）：一个或多个进程的集合，每一个进程组有唯一一个进程组ID，即进程组长进程的ID。 会话期（session）：一个或多个进程组的集合，有唯一一个会话期首进程（session leader）。会话期ID为首进程的ID。 会话期可以有一个单独的控制终端（controlling terminal）。与控制终端连接的会话期首进程叫做控制进程（controlling process）。当前与终端交互的进程称为前台进程组。其余进程组称为后台进程组。 根据POSIX.1定义：

前面已经介绍了Gitlab环境部署记录，这里简单说下Gitlab的备份和恢复操作记录： 1）Gitlab的备份目录路径设置 1 2 3 4 5 6 7 8 9 10 11 12 [root@code-server ~]# vim /etc/gitlab/gitlab.rb gitlab_rails[‘manage_backup_path’] = true

需求 公司出于自身隐私保护需要,不想把自己的代码开源到包管理区，但是又急需一套完整包管工具，来管理越来越多的组件、模块和项目。对于前端，最熟悉的莫过于npm，bower等；但是bower的市场兼容性明显没有npm强壮，加之commonjs规范的日益成熟。npm应该是前端包管理的不二选择。 公司对于搭建本地私有npm库有如下要求： 私有包托管在内部服务器中 项目中使用了公共仓库上的公共包，也使用了内部服务器上的私有包 希望下载的时候，公共包走公共仓库，私有包走内部服务器的私有仓库 服务器硬盘有限，希望只缓存下载过的包，而不是全部同步。 对于下载，发布npm包有对应的权限管理，安装方便，配置简单，依赖少。 关于sinopia？ Sinopia 是一个零配置的私有的带缓存功能的npm包管理工具，作者是是rlidwka，一个大神，也是一只猫～ 往社区内贡献过很多代码，包括 jshttp, markdown-it 等等，也是 Node.js 核心代码库的活跃贡献者。 使用sinopia，你不用安装CouchDB或MYSQL之类的数据库，Sinopia有自己的迷你数据库，如果要下载的包不存在，它将自动去你配置的npm地址上去下载，而且硬盘中只缓存你现在过的包，以节省空间。 为什么选择sinopia sinopia有以下几个优势值得关注： 不同步拉取npm库，占据大量硬盘，没有硬盘被撑爆的问题；

https://github.com/rlidwka/sinopia/issues/399 Unable to resolve dependencies like “@angular/common” Hi, first you must update your config.yaml section: packages: ‘@*/*’: # scoped packages

目录 登录 系统配置情况命令 系统 资源 磁盘和分区 网络 进程查看 系统时间 用户 常用命令 系统的关机、重启以及登出 查看网络配置的命令 查看linux进程 杀进程 查看用户的命令 log日志查看 查看系统服务的命令 安装程序的命令 获取帮助的命令

发表于2014-08-15 10:05| 22682次阅读| 来源High Scalability| 57 条评论| 作者Todd Hoff 大数据架构HAProxyPHPRedisMySQL 摘要：着眼创业公司，应用程序架构主要考虑因素不只是技术，成本效益同样必不可少。因此，对于优秀的架构师，基于遗留系统、已有开发团队，以最小成本构造出可持续应用才是王道。 【编者按】在公司的发展中，保证服务器的可扩展性对于扩大企业的市场需要具有重要作用，因此，这对架构师提出了一定的要求。Octivi联合创始人兼软件架构师Antoni Orfin将向你介绍一个非常简单的架构，使用HAProxy、PHP、Redis和MySQL就能支撑每周10亿请求。同时，你还能了解项目未来的横向扩展途径及常见的模式。 以下为译文：   在这篇文章中，我将展示一个非常简单的架构，使用HAProxy、PHP、Redis和MySQL支撑每周10亿请求。除此之外，我还将展示项目未来的横向扩展途径及常见的模式，下面我们一起看细节。 状态： 服务器 3个应用程序节点 2个MySQL+1个备份 2个Redis 应用程序 应用程序每周处理10亿请求

https://github.com/liukelin/canal_mysql_nosql_sync 下图是最基本的web服务器的结构图。  基于 Canal 的 MySql RabbitMQ Redis/memcached/mongodb 的nosql同步 （多读、nosql延时不严格 需求） 1.mysql主从配置 2.对mysql binlog(row) parser 这一步交给canal 3.MQ对解析后binlog增量数据的推送 4.对MQ数据的消费（接收+数据解析，考虑消费速度，MQ队列的阻塞） 5.数据写入/修改到nosql （redis的主从/hash分片）