Rainbond:如何制作一个可分享的云市应用?

应用是Rainbond可管理的最小服务单元,用户可以将多个应用组成一个复杂的业务系统,这套业务系统可以对外提供服务,也可以分享给其他组织独立部署。本文将会通过Solo+Pinpoint(Pinpoint-java性能分析最佳实践)这个例子,演示“如何制作一个可分享的云市应用”, 分享后的应用可供团队、公司或云市的用户一键安装部署完整的服务体系,实现标准化得一键交付部署。 对于还没有了解Rainbond,或者还没有成功安装Rainbond的同学,建议先到以下的两个链接进行学习: Rainbond介绍 Rainbond一键部署 创建应用 应用的创建有3种方式,分别是从源码创建、从Docker镜像创建和从应用市场安装,详情请参见:创建一个应用 接下来将会用从源码创建和从应用市场安装—— 同步应用到内部市场 »

微服务间的通信如何选择

Melvin Koh 如果我们想要构建一个生产就绪的系统,那么必须要权衡所有因素,其中选择微服务间的连接方法更是其中的一个难点。 作者在本文中介绍了一些常见的通信方法,并简要概述了其项目背景以及为何最终选择了RPC。 在决定微服务间连接方法前,我们需要搞清楚两个概念: 架构风格(Architectural Style) 传输协议(Transport Protocol) 架构风格 在使用服务时如何形成有效负载?是有状态还是无状态?我们应该采用REST、SOAP、JSON、XML,还是其他消息格式? 传输协议 我们应该用哪种传输协议?应该采用HTTP、 »

那些微服务和技术堆栈教我们的事

Ashish Sharma在本文中将谈谈企业技术堆栈主流是如何一步步走向微服务架构的,并分享一些经验教训。 过去的技术堆栈如下图所示: 在应用层,我们有一个用Windows form和WPF编写的桌面客户端。应用与服务层对话,而服务层是完全用c#编写的SOA体系结构。这是我们(当时)唯一可以使用的语言。它们是通过WCF相互通信的单片有状态服务。我们使用SQL server作为后端存储。所有这些都在内部部署,这意味着我们的客户购买我们的软件并将其托管在自己的硬件上。 我在金融行业工作(股市准确),是公有云的后期采用者。这个行业不喜欢将数据放在公共云上的想法。我见过的客户会阻止与外部世界进行任何可能的通信,以防止数据泄漏。但随着技术的成熟,种心态已经发生了巨大的变化, »

关于微服务CD的5点思考

持续交付是任何软件交付实践的重要组成部分。无论目标部署环境如何,我们都应该设计CD工作流,以便将软件的任何更改投入生产。 对于微服务架构来说同样如此。本文将分享作者Sheroy Marker在架构设计和应用开发中的一些关于CD工作流的思考和经验。 微服务和CD 按照Martin Fowler的说法,微服务架构是“将软件设计一组为可独立部署的服务的方式“。这种方式目前已经成为构建分布式系统/应用的主流;按照Jez Humble的说法,CD(持续交付)是“能够以可持续的方式安全快速地将所有类型的变更 - 包括新功能、配置、错误修复和实验 - 投入生产” »

微服务架构选Java还是选Go - 多用户负载测试

Ivan Nikitsenka 微服务架构允许我们再创建新应用时自由选择不同的技术和编程语言。不过究竟哪种语言更适合我们当下的硬件?回答这个问题,需要搞明白Java和Go编写的相同应用程序之间的性能差异。 先决条件 不采用其他性能增强功能 使用默认框架和库设置的最小配置 没有ORM框架 使用纯DB驱动程序和相同的SQL查询 用于Java的Postgres JDBC 4.2驱动程序和用于Go的github.com/lib/pq 怎么做 使用DB(Postgres)数据存储创建简单的Java/Go REST API应用程序 使用JMeter或类似工具创建负载测试 »