The Eventuate™ Platform for developing transactional microservices. It provides simple yet powerful event-driven programming models that solve the distributed data management problems inherent in a microservice architecture. The platform supports two different programming models: Eventuate Tram for microservices that use traditional JDBC/JPA-based…
Context You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might…
摘要： 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》在InfoQ上的一个分 概述 关于微服务的介绍，可以参考微服务那点事。 微服务是最近非常火热的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen 《远距离条件下的康威定律——分布式世界中实现团队构建》（是Design RESTful API的作者）在InfoQ上的一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway’s Law）。 在康威的这篇文章中，最有名的一句话就是： Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – Melvin Conway(1967) 中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。看看下面的图片（来源于互联网，侵删），再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。 用通俗的说法就是：组织形式等同系统设计。 这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论，结果程序员屌丝的文章不入商业人士的法眼，无情被拒，康威就投到了一个编程相关的杂志，所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其“吹捧”成了现在我们熟知“康威定律”。 康威定律详细介绍…
摘要： 微服务架构被提出很短的时间内，就被越来越多的开发人员推崇，简单来说其主要的目的是有效的拆分应用，实现敏捷开发和部署 。本分享即尝试介绍微服务架构的一些实施细节和要求，探询微服务架构的由来，并最终提供我们团队内部的一些实践总结，希望对大家有帮助。 WHAT – 什么是微服务 微服务简介 这次参加JavaOne2015最大的困难就是听Microservice相关的session，无论内容多么水，只要题目带microservice，必定报不上名，可见Microservice有多火。最喜欢其中一页。关于这个典故，可以参考[this]( )，此图适用于一切高大上的名字——技术有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比较适合小项目，优点是： 开发简单直接，集中式管理 基本不会重复开发 功能都在本地，没有分布式的管理开销和调用开销 它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）： 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断 代码维护难：代码功能耦合在一起，新人不知道何从下手 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉 扩展性不够：无法满足高并发情况下的业务需求 所以，现在主流的设计一般会采用Microservice Architecture，就是基于微服务的架构。简单来说， 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。 用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。你看，我们叫分库分表，别人总结成了scale cube，这就是抽象的能力啊，把复杂的东西用最简单的概念解释和总结。X轴代表运行多个负载均衡器之后运行的实例，Y轴代表将应用进一步分解为微服务（分库），数据量大时，还可以用Z轴将服务按数据分区（分表） 微服务的具体特征 先看看最官方的定义吧 The microservice…
你是不是经常需要 SSH 或者 telent 远程登录到 Linux 服务器？你是不是经常为一些长时间运行的任务而头疼，比如系统备份、ftp 传输等等。通常情况下我们都是为每一个这样的任务开一个远程终端窗口，因为他们执行的时间太长了。必须等待它执行完毕，在此期间可不能关掉窗口或者断开连接，否则这个任务就会被杀掉，一切半途而废了。 元凶：SIGHUP 信号 让我们来看看为什么关掉窗口/断开连接会使得正在运行的程序死掉。 在Linux/Unix中，有这样几个概念： 进程组（process group）：一个或多个进程的集合，每一个进程组有唯一一个进程组ID，即进程组长进程的ID。 会话期（session）：一个或多个进程组的集合，有唯一一个会话期首进程（session leader）。会话期ID为首进程的ID。 会话期可以有一个单独的控制终端（controlling terminal）。与控制终端连接的会话期首进程叫做控制进程（controlling process）。当前与终端交互的进程称为前台进程组。其余进程组称为后台进程组。 根据POSIX.1定义： 挂断信号（SIGHUP）默认的动作是终止程序。 当终端接口检测到网络连接断开，将挂断信号发送给控制进程（会话期首进程）。 如果会话期首进程终止，则该信号发送到该会话期前台进程组。 一个进程退出导致一个孤儿进程组中产生时，如果任意一个孤儿进程组进程处于STOP状态，发送SIGHUP和SIGCONT信号到该进程组中所有进程。 因此当网络断开或终端窗口关闭后，控制进程收到SIGHUP信号退出，会导致该会话期内其他进程退出。 我们来看一个例子。打开两个SSH终端窗口，在其中一个运行top命令。 1 [root@tivf09 root]# top 在另一个终端窗口，找到top的进程ID为5180，其父进程ID为5128，即登录shell。 1 2 3 [root@tivf09 root]# ps -ef|grep top root …
前面已经介绍了Gitlab环境部署记录，这里简单说下Gitlab的备份和恢复操作记录： 1）Gitlab的备份目录路径设置 1 2 3 4 5 6 7 8 9 10 11 12 [root@code-server ~]# vim gitlab_rails[‘manage_backup_path’] = true gitlab_rails[‘backup_path’] = “/data/gitlab/backups” //gitlab备份目录 gitlab_rails[‘backup_archive_permissions’] = 0644 //生成的备份文件权限 gitlab_rails[‘backup_keep_time’] = 7776000 //备份保留天数为3个月（即90天，这里是7776000秒） [root@code-server ~]# mkdir -p /data/gitlab/backups [root@code-server ~]# chown -R git.git /data/gitlab/backups [root@code-server…
需求 公司出于自身隐私保护需要,不想把自己的代码开源到包管理区，但是又急需一套完整包管工具，来管理越来越多的组件、模块和项目。对于前端，最熟悉的莫过于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库，占据大量硬盘，没有硬盘被撑爆的问题； 安装配置极其简单,不需要数据库； 支持配置上游registry配置，一次拉取即缓存； 支持forever及pm2守护进程管理； 其他方法 使用 git+ssh 这种方式直接引用到 GitHub 项目地址 嗯，这种方式可行，也最简单，但真真的太烂了，姑且不说不能使用 semver，关键还是 url 太丑，如果是强迫症真的没法忍～ 使用cnpm 暂且不论 cnpm 只是作为镜像使用，其实这个方案缺点就挺多的，用的人多，速度不一定快，缓存，关键是不支持发布包以及登陆、注册，再加上配置过于复杂。而且，还需要安装数据库。 npm on-site 土豪啊，我还能说什么呢。。。但是问题是，npm在国内访问慢，还是不是的无法访问，花钱也买不到好的服务，何必呢。…
Unable to resolve dependencies like “@angular/common” Hi, first you must update your config.yaml section: packages: ‘@*/*’: # scoped packages access: $all publish: $authenticated proxy: npmjs in default config.yaml there is no proxy setting. If anyone has this problem,…
目录 登录 系统配置情况命令 系统 资源 磁盘和分区 网络 进程查看 系统时间 用户 常用命令 系统的关机、重启以及登出 查看网络配置的命令 查看linux进程 杀进程 查看用户的命令 log日志查看 查看系统服务的命令 安装程序的命令 获取帮助的命令 安装软件方法 yum错误 安装源 下载 登录 username:root password:安装时设置的密码 其它终端登录 $ ssh root@192.168.0.23 系统配置情况命令 系统 cat /etc/redhat-release # CentOS 查看系统信息 uname -a #…
发表于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亿请求 峰值700请求每秒的单Symfony2实例（平均工作日约550请求每秒） 平均响应时间30毫秒 Varnish，每秒请求超过1.2万次（压力测试过程中获得） 数据存储 Redis储存了1.6亿记录，数据体积大约100GB，同时它是我们的主要数据存储 MySQL储存了3亿记录，数据体积大约300GB，通常情况下它作为三级缓存层 平台： 监视： Icinga Collectd 应用程序 HAProxy + Keepalived Varnish PHP（PHP-FPM）+ Symfony2 Framework 数据存储…