Fork me on GitHub
摘要: 在使用 RabbitMQ 的时候,作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两个选项用来控制消息的投递可靠性模式。 rabbitmq 整个消息投递的路径为: producer->rabbitmq broker cluster->exchange->queue->consumer message 从 producer 到 rabbitmq broker cluster 则会返回一个 confirmCallback 。 message 从 exchange->queue 投递失败则会返回一个 returnCallback 。我们将利用这两个 callback 控制消息的最终一致性和部分纠错能力。阅读全文
posted @ 2018-07-28 11:57 王清培 阅读(622) 评论(0) 编辑
摘要: 最近一段时间内结束了数据库表拆分项目,这里做个简单的小结。 本次拆分主要包括订单和优惠券两大块,这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展,不管是存储的要求,还是写入、读取的性都基本上到了警戒水位。 订单是交易的核心,优惠券是营销的核心,这两块基本上是整个平台的正向最核心部分。为了支持未来三到五年的快速发展,我们需要对数据进行拆分。 数据库表拆分业内已经有很多成熟方案,已经不是什么高深的技术,基本上是纯工程化的流程,但是能有机会进行实际的操刀一把机会还是难得,所以非常有必要做个总结。阅读全文
posted @ 2018-07-21 17:05 王清培 阅读(501) 评论(0) 编辑
摘要: 从 __SOA__ 架构到现在大行其道的微服务架构,系统越拆越小,整体架构的复杂度也是直线上升,我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟(包括典型的数据一致性,系统调用带来的一致性问题,还是跨节点跨机房复制带来的一致性问题都有了很多解决方案),但是有一个环节我们明显忽略了。 在现在的微服务架构趋势下,微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看,上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。阅读全文
posted @ 2018-07-08 14:32 王清培 阅读(660) 评论(1) 编辑
摘要: 标签: 上海线下技术交流会 作者:王清培(Plen wang) 沪江Java资深架构师 、营销云平台负责人 上海地区技术线下交流,本次聚会AA制,要的就是热爱技术,交流技术,不是凑热闹。特此留念。 活动日程: 主题:电商平台架构设计 讲解人:王清培 居住地:上海 沪江 Java 架构师 、畅销书作者阅读全文
posted @ 2018-04-16 15:55 王清培 阅读(502) 评论(7) 编辑
摘要: 标签: 花旗金融培训 作者:王清培(Plen wang) 沪江Java资深架构师 、营销云平台负责人 受邀给花旗金融(上海)培训,一直没时间整理,特此留念。 谢谢。阅读全文
posted @ 2018-04-16 15:13 王清培 阅读(348) 评论(0) 编辑
摘要: 说到 ___hash table___ 有两个东西是我们经常会碰到的,首先就是 ___hash 碰撞___ 问题,__redis dict__ 是采用链地址法来解决,___dictEntry->next___ 就是指向下个冲突 __key__ 的节点。 还有一个经常碰到的就是 __rehash__ 的问题,提到 __rehash__ 我们还是有点担心性能的。那么redis 实现是非常巧妙的,采用 ___惰性渐进式 rehash 算法___ 。阅读全文
posted @ 2018-01-27 09:24 王清培 阅读(532) 评论(0) 编辑
摘要: redis 为我们提供了 5 种数据类型,基本上我们使用频率最高的就是 string ,而对其他四种数据类型使用的频次稍弱于 string 。 一方面是由于 string 使用起来比较简单,可以方便存储复杂大对象,使用场景比较多。还有一个原因就是由于 redis expire time 只能设置在 key 上,像 list、hash、set、zset 属于集合类型,会管理一组 item,我们无法在这些集合的 item 上设置过期时间,所以使用 expire time 来处理集合的 cache 失效会变得稍微复杂些。但是 string 使用 expire time 来管理过期策略会比较简单,因为它包含的项少。这里说的集合是宽泛的类似集合。 导致我们习惯性的使用 string阅读全文
posted @ 2018-01-21 11:05 王清培 阅读(1066) 评论(1) 编辑
摘要: 最近大半年内有过两次负责性能压测的一些工作。一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题,所以总结下性能压测的一般性实践。但是问题肯定不止这些,还有更多深层次的问题等着发现,等我们遇到了在逐个解决再来总结分享。 做性能压测的原因就不多说了,一般两个时间点是必须要做的,大促前、新系统上线。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内,做到心中有数。阅读全文
posted @ 2017-12-02 09:51 王清培 阅读(1306) 评论(3) 编辑
摘要: 在之前的一次性能压测的时候我们发现一个细节问题,我们使用 __spring boot__ 创建的 __web rest__ 项目,使用默认 __spring mvc__ 作为 __web rest__ 框架。 这在使用上没有太大问题,但是有一个影响性能的细节问题被发现了,说实话这个问题很难被发现。阅读全文
posted @ 2017-11-26 12:29 王清培 阅读(941) 评论(2) 编辑
摘要: 最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码、debug、fixbug都逐渐收尾,进入上线前的性能压测。 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数。 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务)。(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举。) 废话不多说了,直接进入主题。 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务、查单服务。查单服务初步压测下来问题不大,主要是db的索引和cache的问题。 下单服务有两个核心接口,预订单查询、创建订单。预订单查询主要是订单的前置状态的结算页汇总计算(不仅是结算页),不落具体订单,如,各阅读全文
posted @ 2017-09-23 14:38 王清培 阅读(816) 评论(6) 编辑
摘要: 最近一段时间与redis接触比较频繁。发现有些东西还是工作中经常会用到的,自己也花了点时间巩固下。本篇文章主要是以总结性的方式梳理,因为redis的主题很大,任何一个技术点展开都是几篇文章的量。也可以说这篇文章是个概览。阅读全文
posted @ 2017-07-29 15:35 王清培 阅读(2096) 评论(9) 编辑
摘要: .NET程序员转向JAVA领域,必备技术首当其冲就是JAVA Concurrency 并发编程。 最近系统性的学习了 Doug Lea 《JAVA并发编程实战》一书。这书很有嚼劲,进入JAVA技术体系必看书籍之一。 看完之后,在公司内部做了一个简单的内部分享,主要是普及下.NET程序员转向Java技术后对于并发的基本认识。阅读全文
posted @ 2017-07-15 11:33 王清培 阅读(1110) 评论(4) 编辑
摘要: 最近在使用alibaba druid进行多数据源连接的时候无意中发现一个小bug,已经提交github issue 官方已经fix。issue 地址:https://github.com/alibaba/druid/issues/1796阅读全文
posted @ 2017-07-08 12:49 王清培 阅读(2451) 评论(1) 编辑
摘要: redis setnx 命令特性 当指定key不存在时才设置。也就是说,如果返回1说明你的命令被执行成功了,redis服务器中的key是你之前设置的值。如果返回0,说明你设置的key在redis服务器里已经存在。阅读全文
posted @ 2017-06-18 14:15 王清培 阅读(1339) 评论(6) 编辑
摘要: 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下。 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C、UGC、直播等)。平台中核心之一的就是订单域相关服务,下单服务、查单服务、支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单、结算、跳支付中心。每次业务方进行大促期间平台都要进行一次常规压测,做到心里有底。 在压测的上半场,陆续的解决一些不是太奇怪的问题,定位到问题时间都在计划内。下单服务、查单服务、结算页都顺利压测通过。但是到了支付回调服务压测的时候,有个奇怪的问题出现了。阅读全文
posted @ 2017-06-04 15:40 王清培 阅读(1499) 评论(7) 编辑
摘要: 最近一段时间公共业务平台在进行大面积的重构,对原来的技术栈进行迁移,逐渐往java、go、node.js等开源、自由为主的技术体系中过度。 虽然这主要是替换技术框架,但也是我们应用系统进行重新设计、业务流程重新梳理的一个好机会,我们将利用这次机会来重构之前发现的一些问题。 Martin Fowler大师《重构》一书中有说过一句话,大概意思就是,“每次对原有系统进行修改调整的时候是一个非常好的重构契机。”阅读全文
posted @ 2017-06-03 08:09 王清培 阅读(6364) 评论(18) 编辑
摘要: 在通常情况下你在使用消息中间件的时候,都是未经设计的使用,你没有把应用架构和系统架构边界搞清楚。消息中间件只是一个纯粹的技术工具,当你引入的时候是站在应用架构的角度引入的。这是架构的角度,也是架构的上帝视角,这样你就不会用到最后发现越来越混乱,而且也无法结合软件模式、方法论、最佳实践来综合提升系统的架构能力。 EDA(Event Driven Architecture,EDA) 事件驱动架构,它是一种用来在SOA或者Micro service中进行的架构模式。它的好处有几个,柔性具有很高的伸缩性。阅读全文
posted @ 2016-12-10 19:46 王清培 阅读(20987) 评论(7) 编辑
摘要: .NET架构设计系列文章 .NET框架设计系列文章汇总阅读全文
posted @ 2016-11-13 09:33 王清培 阅读(11698) 评论(46) 编辑
摘要: 聊下 git rebase -i 聊下git merge --squash阅读全文
posted @ 2016-11-03 11:15 王清培 阅读(725) 评论(0) 编辑
摘要: 两年前有机会接触过elasticsearch,但是未做深入学习,只是工作中用到了。越来越发现es是个不错的好东西,所以花了点时间好好学习了下。在学习过程中也发现了一些问题,网上大多资料都很零散,大部分都是实验性的demo,很多问题并没有讲清楚也并没有系统的讲完整一整套方案,所以耐心的摸索和总结了一些东西分享出来。 毕竟当你用生产使用的标准来使用es时会有很多问题,这对你的学习提出来了新的标准。 比如,使用elasticsearch servicewrapper进行自启动的时候难道就没发现它的配置中有一个小bug导致load不了elasticsearch jar包中的class吗。 还有es不同版本之间的差异巨大,比如,1.0中的分布式rout阅读全文
posted @ 2016-10-16 19:00 王清培 阅读(21954) 评论(30) 编辑
摘要: 在使用 RabbitMQ 的时候,作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两个选项用来控制消息的投递可靠性模式。 rabbitmq 整个消息投递的路径为: producer->rabbitmq broker cluster->exchange->queue->consumer message 从 producer 到 rabbitmq broker cluster 则会返回一个 confirmCallback 。 message 从 exchange->queue 投递失败则会返回一个 returnCallback 。我们将利用这两个 callback 控制消息的最终一致性和部分纠错能力。阅读全文
posted @ 2018-07-28 11:57 王清培 阅读(622) 评论(0) 编辑
摘要: 最近一段时间内结束了数据库表拆分项目,这里做个简单的小结。 本次拆分主要包括订单和优惠券两大块,这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展,不管是存储的要求,还是写入、读取的性都基本上到了警戒水位。 订单是交易的核心,优惠券是营销的核心,这两块基本上是整个平台的正向最核心部分。为了支持未来三到五年的快速发展,我们需要对数据进行拆分。 数据库表拆分业内已经有很多成熟方案,已经不是什么高深的技术,基本上是纯工程化的流程,但是能有机会进行实际的操刀一把机会还是难得,所以非常有必要做个总结。阅读全文
posted @ 2018-07-21 17:05 王清培 阅读(501) 评论(0) 编辑
摘要: 从 __SOA__ 架构到现在大行其道的微服务架构,系统越拆越小,整体架构的复杂度也是直线上升,我们一直老生常谈的微服务架构下的技术难点及解决方案也日渐成熟(包括典型的数据一致性,系统调用带来的一致性问题,还是跨节点跨机房复制带来的一致性问题都有了很多解决方案),但是有一个环节我们明显忽略了。 在现在的微服务架构趋势下,微服务在运维层面和自动化部署方面基本上是比较完善了。从我个人经验来看,上层的开发、测试对微服务架构带来的巨大变化还在反应和学习中。阅读全文
posted @ 2018-07-08 14:32 王清培 阅读(660) 评论(1) 编辑
摘要: 标签: 上海线下技术交流会 作者:王清培(Plen wang) 沪江Java资深架构师 、营销云平台负责人 上海地区技术线下交流,本次聚会AA制,要的就是热爱技术,交流技术,不是凑热闹。特此留念。 活动日程: 主题:电商平台架构设计 讲解人:王清培 居住地:上海 沪江 Java 架构师 、畅销书作者阅读全文
posted @ 2018-04-16 15:55 王清培 阅读(502) 评论(7) 编辑
摘要: 标签: 花旗金融培训 作者:王清培(Plen wang) 沪江Java资深架构师 、营销云平台负责人 受邀给花旗金融(上海)培训,一直没时间整理,特此留念。 谢谢。阅读全文
posted @ 2018-04-16 15:13 王清培 阅读(348) 评论(0) 编辑
摘要: 说到 ___hash table___ 有两个东西是我们经常会碰到的,首先就是 ___hash 碰撞___ 问题,__redis dict__ 是采用链地址法来解决,___dictEntry->next___ 就是指向下个冲突 __key__ 的节点。 还有一个经常碰到的就是 __rehash__ 的问题,提到 __rehash__ 我们还是有点担心性能的。那么redis 实现是非常巧妙的,采用 ___惰性渐进式 rehash 算法___ 。阅读全文
posted @ 2018-01-27 09:24 王清培 阅读(532) 评论(0) 编辑
摘要: redis 为我们提供了 5 种数据类型,基本上我们使用频率最高的就是 string ,而对其他四种数据类型使用的频次稍弱于 string 。 一方面是由于 string 使用起来比较简单,可以方便存储复杂大对象,使用场景比较多。还有一个原因就是由于 redis expire time 只能设置在 key 上,像 list、hash、set、zset 属于集合类型,会管理一组 item,我们无法在这些集合的 item 上设置过期时间,所以使用 expire time 来处理集合的 cache 失效会变得稍微复杂些。但是 string 使用 expire time 来管理过期策略会比较简单,因为它包含的项少。这里说的集合是宽泛的类似集合。 导致我们习惯性的使用 string阅读全文
posted @ 2018-01-21 11:05 王清培 阅读(1066) 评论(1) 编辑
摘要: 最近大半年内有过两次负责性能压测的一些工作。一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题,所以总结下性能压测的一般性实践。但是问题肯定不止这些,还有更多深层次的问题等着发现,等我们遇到了在逐个解决再来总结分享。 做性能压测的原因就不多说了,一般两个时间点是必须要做的,大促前、新系统上线。压测都是为了系统在线上的处理能力和稳定性维持在一个标准范围内,做到心中有数。阅读全文
posted @ 2017-12-02 09:51 王清培 阅读(1306) 评论(3) 编辑
摘要: 在之前的一次性能压测的时候我们发现一个细节问题,我们使用 __spring boot__ 创建的 __web rest__ 项目,使用默认 __spring mvc__ 作为 __web rest__ 框架。 这在使用上没有太大问题,但是有一个影响性能的细节问题被发现了,说实话这个问题很难被发现。阅读全文
posted @ 2017-11-26 12:29 王清培 阅读(941) 评论(2) 编辑
摘要: 在使用 git 的时候我们都会面临多账户问题,比较常见的就是公司内部的 gitlab,开源平台 github ,我们都需要在一台电脑上同时使用,这需要解决两个问题。阅读全文
posted @ 2017-11-18 14:00 王清培 阅读(209) 评论(0) 编辑
摘要: 最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码、debug、fixbug都逐渐收尾,进入上线前的性能压测。 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数。 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务)。(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举。) 废话不多说了,直接进入主题。 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务、查单服务。查单服务初步压测下来问题不大,主要是db的索引和cache的问题。 下单服务有两个核心接口,预订单查询、创建订单。预订单查询主要是订单的前置状态的结算页汇总计算(不仅是结算页),不落具体订单,如,各阅读全文
posted @ 2017-09-23 14:38 王清培 阅读(816) 评论(6) 编辑
摘要: 最近一段时间与redis接触比较频繁。发现有些东西还是工作中经常会用到的,自己也花了点时间巩固下。本篇文章主要是以总结性的方式梳理,因为redis的主题很大,任何一个技术点展开都是几篇文章的量。也可以说这篇文章是个概览。阅读全文
posted @ 2017-07-29 15:35 王清培 阅读(2096) 评论(9) 编辑
摘要: .NET程序员转向JAVA领域,必备技术首当其冲就是JAVA Concurrency 并发编程。 最近系统性的学习了 Doug Lea 《JAVA并发编程实战》一书。这书很有嚼劲,进入JAVA技术体系必看书籍之一。 看完之后,在公司内部做了一个简单的内部分享,主要是普及下.NET程序员转向Java技术后对于并发的基本认识。阅读全文
posted @ 2017-07-15 11:33 王清培 阅读(1110) 评论(4) 编辑
摘要: 最近在使用alibaba druid进行多数据源连接的时候无意中发现一个小bug,已经提交github issue 官方已经fix。issue 地址:https://github.com/alibaba/druid/issues/1796阅读全文
posted @ 2017-07-08 12:49 王清培 阅读(2451) 评论(1) 编辑
摘要: redis setnx 命令特性 当指定key不存在时才设置。也就是说,如果返回1说明你的命令被执行成功了,redis服务器中的key是你之前设置的值。如果返回0,说明你设置的key在redis服务器里已经存在。阅读全文
posted @ 2017-06-18 14:15 王清培 阅读(1339) 评论(6) 编辑
摘要: 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下。 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C、UGC、直播等)。平台中核心之一的就是订单域相关服务,下单服务、查单服务、支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单、结算、跳支付中心。每次业务方进行大促期间平台都要进行一次常规压测,做到心里有底。 在压测的上半场,陆续的解决一些不是太奇怪的问题,定位到问题时间都在计划内。下单服务、查单服务、结算页都顺利压测通过。但是到了支付回调服务压测的时候,有个奇怪的问题出现了。阅读全文
posted @ 2017-06-04 15:40 王清培 阅读(1499) 评论(7) 编辑
摘要: 最近一段时间公共业务平台在进行大面积的重构,对原来的技术栈进行迁移,逐渐往java、go、node.js等开源、自由为主的技术体系中过度。 虽然这主要是替换技术框架,但也是我们应用系统进行重新设计、业务流程重新梳理的一个好机会,我们将利用这次机会来重构之前发现的一些问题。 Martin Fowler大师《重构》一书中有说过一句话,大概意思就是,“每次对原有系统进行修改调整的时候是一个非常好的重构契机。”阅读全文
posted @ 2017-06-03 08:09 王清培 阅读(6364) 评论(18) 编辑
摘要: 在通常情况下你在使用消息中间件的时候,都是未经设计的使用,你没有把应用架构和系统架构边界搞清楚。消息中间件只是一个纯粹的技术工具,当你引入的时候是站在应用架构的角度引入的。这是架构的角度,也是架构的上帝视角,这样你就不会用到最后发现越来越混乱,而且也无法结合软件模式、方法论、最佳实践来综合提升系统的架构能力。 EDA(Event Driven Architecture,EDA) 事件驱动架构,它是一种用来在SOA或者Micro service中进行的架构模式。它的好处有几个,柔性具有很高的伸缩性。阅读全文
posted @ 2016-12-10 19:46 王清培 阅读(20986) 评论(7) 编辑
摘要: 最近的工作我在做一个有关于消息发送和接受封装工作。大概流程是这样的,消息中间件是采用rabbitmq,为了保证消息的绝对无丢失,我们需要在发送和接受前对消息进行DB落地。在发送前我会先进行DB的插入,单表插入,所以在性能上也是能接受的,单表插入做了压测基本上是一到两毫秒的时间,加上消息的发送(有ACK)再加上集群是两个节点的高可用(一个磁盘持久化节点),单台TPS基本上是在2000-3000左右。这对于我们的业务场景来说是够用了。一旦当消息丢失或者由于网络问题、集群问题业务不会中断,消息就算发不出去也没关系,我们会进行消息的补偿或者同步api调用补偿。这是架构设计的必须要考虑的A计划、B计划、C计划,这是敬畏或者危机意识。阅读全文
posted @ 2016-11-27 20:06 王清培 阅读(3995) 评论(8) 编辑
摘要: 最近在使用log4net的时候有一个简单的需求,就是自定义个格式化输出符。这个输出符是专门用来帮我记录下业务ID、业务类型的。比如,“businessID:328593,businessType: orderID”。类似这样的输出日志。这些日志会被elk agent提取送到日志中心ES中,用来进行辅助排障。 简单的看了下log4net的PatternLayout和PatternConverter两个对象的作用,实现起来也是非常方便的。log4net有一组global的PatternLayout,这些全局的格式化对象是默认构造的时候就存在了,我们只需要提供对我们来说特殊场景的实现即可。阅读全文
posted @ 2016-11-20 11:30 王清培 阅读(2515) 评论(0) 编辑
摘要: 在使用git的时候,不管你的服务器是开源平台github还是私服gitlab,你都需要clone仓库到本地,这个clone的时候就需要你选择连接方式。这个连接方式决定了你与服务器交互的时候以一个什么协议进行。如果你没搞清楚这两种方式,可能你在使用的时候会很困惑,别人在push代码的时候没有提示输入账号密码,而你却有,至少我当初有过这个问题。 可选择的协议有https、ssh两种,这从git repository仓库的地址就能分辨出来。阅读全文
posted @ 2016-11-19 11:00 王清培 阅读(1392) 评论(0) 编辑
摘要: .NET架构设计系列文章 .NET框架设计系列文章汇总阅读全文
posted @ 2016-11-13 09:33 王清培 阅读(11698) 评论(46) 编辑
摘要: 在你经常使用的命令当中有一个git branch –a 用来查看所有的分支,包括本地和远程的。但是时间长了你会发现有些分支在远程其实早就被删除了,但是在你本地依然可以看见这些被删除的分支。 你可以通过命令,git remote show origin 来查看有关于origin的一些信息,包括分支是否tracking。阅读全文
posted @ 2016-11-13 09:08 王清培 阅读(4193) 评论(1) 编辑
摘要: 有一种场景是经常发生的。 大家都基于develop拉出分支进行并行开发,这里的分支可能是多到数十个。然后彼此在进行自己的逻辑编写,时间可能需要几天或者几周。在这期间你可能需要时不时的需要pull下远程develop分支上的同事的提交。这是个好的习惯,这样下去就可以避免你在一个无用的代码上进行长期的开发,回头来看这些代码不是新的代码。甚至是会面临很多冲突需要解决,而这个时候你可能还需要对冲突的部分代码进行测试回归,这就很麻烦了。 那么我们来看一下你在pull时候需要习惯性的加上—rebase参数,这样可以避免很多问题。--rebase的本意是想让事情的发展看起来很连续和优美,而不是多出很多无用的merge commit 。 你在有些时候pull代码的时候会有这样的一个提示:阅读全文
posted @ 2016-11-12 14:14 王清培 阅读(12804) 评论(5) 编辑
摘要: 你经常会面临着将dev分支或者很多零散的分支merge到一个公共release分支里。 但是有一种情况是需要你处理的,就是在你的dev的分支里有很多commit记录。而这些commit是无需在release里体现的。 develop 主分支阅读全文
posted @ 2016-11-03 11:56 王清培 阅读(2799) 评论(0) 编辑
摘要: 聊下 git rebase -i 聊下git merge --squash阅读全文
posted @ 2016-11-03 11:15 王清培 阅读(725) 评论(0) 编辑
摘要: 在使用git作为源代码管理工具的时候,开发的时经常会面临一个常见的问题,多个commit 需要合并为一个完整的commit提交。 在一个基本的迭代周期里,你会有很多次commit,有跟配置文件相关的,有跟代码相关的,甚至有跟下次发布fixbug相关的。这些都是你在完成本地开发的时候一个变化记录而已。但是当你需要将你的迭代项目作为一次发布提交时就需要整合所有之前提交的那些很零碎的commit。 根据基本规范,你的commit应该类似"release:20161023_imageprint",在此commit里应该是完整的提交。 git branch -a –vv阅读全文
posted @ 2016-10-23 11:35 王清培 阅读(25388) 评论(1) 编辑
摘要: 两年前有机会接触过elasticsearch,但是未做深入学习,只是工作中用到了。越来越发现es是个不错的好东西,所以花了点时间好好学习了下。在学习过程中也发现了一些问题,网上大多资料都很零散,大部分都是实验性的demo,很多问题并没有讲清楚也并没有系统的讲完整一整套方案,所以耐心的摸索和总结了一些东西分享出来。 毕竟当你用生产使用的标准来使用es时会有很多问题,这对你的学习提出来了新的标准。 比如,使用elasticsearch servicewrapper进行自启动的时候难道就没发现它的配置中有一个小bug导致load不了elasticsearch jar包中的class吗。 还有es不同版本之间的差异巨大,比如,1.0中的分布式rout阅读全文
posted @ 2016-10-16 19:00 王清培 阅读(21954) 评论(30) 编辑
摘要: DDD本身的技术就不介绍了,本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明,这是可行的方案。用好DDD是一回事,推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案,但是我只能说DDD非常特殊。 我们都知道自己用好DDD问题不大,让一两个人用好DDD也问题不大。你也许代码控制能力很强,也或者你的组员对DDD都有兴趣,在你的领导下,你让他们编写DDD模式的代码,问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等,这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同,对阅读全文
posted @ 2015-12-05 11:07 王清培 阅读(8561) 评论(61) 编辑
摘要: 这篇文章内容会很短,主要是想给大家分享下我最近在做一个简单的rabbitmq客户端类库的封装的经验总结,说是简单其实一点都不简单。为了节省时间我主要按照Library的执行顺序来介绍,在你看来这里仅仅是一个简单的经验总结,但是在我看来这些经验只有在你真正的封装rabbitmq客户端库的时候且将你的客户端安全稳定的发布上线后才会真的发现这些问题。 比如你的库只是链接单个Node的时候和链接高可用集群的HAProxy时候是完全两回事。当你未能在你的库里使用反向注入LOG接口的时候一旦在线上发生网络解析和序列化等一系列在线问题时候你是多么无能为力。当你使用同步循环获取队列消息的时候一旦发生异常你的链接就会断掉等等这些细节。我总结了我在编写这个library的时候慢慢稳定下来的过程和经验。至少目前来看网络上的文章,当然我是指.NET/C#方面的,都没有讲到这些问题,大阅读全文
posted @ 2015-08-22 21:27 王清培 阅读(11215) 评论(36) 编辑
摘要: 最近对软件开发有了一个新的认识,这个认识源自连续看了两本Craig larman大师的书籍《UML与模式应用》、《精益与敏捷开发大型应用实战》和公司目前的项目情况这两件事情一起碰撞导致的感悟。 先说下前者,为什么会想到看Craig larman大师的书籍。其实我收藏的书籍已经上千本,在各个电商平台上都有帐号,目的只有一个就是收藏好的书籍。家里也堆了很多,没事浏览新书是我现在最大的乐趣。我相信有这种感觉和爱好的不止我一个人,家里堆上几十本书的在IT行业算是很正常的。 书多了有时候不知道要看些什么也很正常,我的原则就是随时调整,看目前所面临的困惑。根据我以往的经验总结,在实际问题面前寻找答案最容易让你有新的感悟和提升。我相信书中自有黄金屋、书中自有颜如玉,要在对的时间看对的书,说白了就是在有困惑的时候就去寻找给你答案的这方面书籍。为什么要看Craig larman大师的书,是因为阅读全文
posted @ 2015-08-01 16:14 王清培 阅读(8030) 评论(25) 编辑
摘要: 最近一段时间都在做系统分析和设计工作,面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易,最大的问题就是职责如何分配。论系统架构设计的最大的问题,其实也就是职责的分配,分配的合理,实现起来就会很柔性,反之就会使架构很混乱。 软件的生命周期大概可以归纳为四个基本的过程,分析、设计、实现、测试,当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程,在这个几个子过程中适当的输出一些过程制品,每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中,不提倡输出任何文档形式的过程制品,也同样有着上述几个过程,强调以人为中心,通过沟通来解决大部分的问题。 不能用好与不好来判断哪一种方法论,只能根阅读全文
posted @ 2015-05-07 21:49 王清培 阅读(67879) 评论(27) 编辑
摘要: 很高兴我的第一本书由图灵出版社出版。本书总结了我这些年来对框架学习、研究的总结,里面纯干货,无半句废话。 书的详情请看互动网的销售页面:http://product.china-pub.com/3770890 精彩推荐: “这本书最大的价值就在于告诉你如何在实战中运用平时学到的知识,如何站在不同的角度分析和解决问题。与市面上其他图书不同,这本书中的内容都是清培在工作中遇到实际问题后分析得出的经验。对我而言,里面的各种设计都具有独到的见解,往往能将复杂的问题简化成优雅的模式。”   ——刘星亮,携程旅行网攻略社区事业部技术经理、架构师      “这本书字里行间都充满了高大上的气息,但又有一种低奢内的大家风范。实在是一本在架构设计方面实用的经验之书、智慧之书。”   ——袁永福,微软MVP、南京都昌信息科技有限公司创办人阅读全文
posted @ 2015-01-27 20:04 王清培 阅读(7575) 评论(813) 编辑
摘要: 随着应用程序的复杂度不断上升,要想将好的设计思想稳定的落实到线上,我们需要具备解决问题的能力。需要具备对运行时的错误进行定位且快速的解决它的能力。本篇文章我将分享一下我对.NET应用程序调试方面的学习和使用总结。 其实对调试程序的使用是不难的,关键是知道它的调试原理才行,因为调试一个程序或者dump文件,都需要了解一定的.NET调试的原理才行,比如你在附加到进程调试时在执行某个SOS扩展命令是需要切换到指定线程上的,而调试dump文件就不需要,但是对Dump文件的分析有些SOS扩展命令是不能用的,类似这样的问题,一旦出现你就一头雾水,所以花点时间学习一下原理是有必要的。阅读全文
posted @ 2014-10-15 21:34 王清培 阅读(16660) 评论(74) 编辑
摘要: 从这篇文章开始我将分享一系列我认为在实际工作中很有必要的一些.NET项目开发的核心技术点,所以我称为必知必会。尽管这一些列是使用.NET/C#来展现,但是同样适用于其他类似的OO技术平台,这些技术点可能称不上完整的技术,但是它是经验的总结,是掉过多少坑之后的觉醒,所以有必要花几分钟时间记住它,在真实的项目开发中你就知道是多么的有帮助。好了,废话不说了,进入主题。 我们在开发服务时为了调试方便会在本地进行一个基本的模块测试,你也可以认为是集成测试,只不过你的测试用例不会覆盖到80%以上,而是一些我们认为在开发时不是很放心的点才会编写适当的用例来测试它。阅读全文
posted @ 2014-09-15 20:18 王清培 阅读(3336) 评论(5) 编辑
摘要: 随着现在的企业应用架构都在向着SOA方向转变,目的就是将一个庞大的业务系统按照业务进行划分,不管从公司的管理上、产品的开发上,这一系列流程来看,都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。 但是本文要说的是,我们都将目光转向到了后端,也就是服务端,而将精力和时间都重点投在了后端服务的架构设计上,渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂,显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险,服务接口都是按照指数级增加,基本上每一个新的业务需求都是提供新的接口,这没有问题。按照服务的设计原则,服务接口就应该有着明确的作用,而不是按照代码的思维来考虑接口的设计。 但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的,是否做好了这种变化带来显示端逻辑复杂的准备。阅读全文
posted @ 2014-09-08 16:24 王清培 阅读(6591) 评论(33) 编辑
摘要: 一直都在谈论面向对象开发,但是开发企业应用系统时,使用面向对象开发最大的问题就是在于,多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用,如果之间的互相操作是在一个业务事务范围内的,很容易完成,但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。 在以往,我们使用过程式的代码(事务脚本模式),将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中,就算你适当的提取重复代码,效果也不大,因为你永远都..阅读全文
posted @ 2014-09-01 21:07 王清培 阅读(3762) 评论(9) 编辑
摘要: 对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来,园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD,为什么会痴迷于它并不是因为它是所谓的新技术,也不是因为各种对它的炒作,而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。 DDD可以很好的指导我们开发可靠的软件系统,尤其是现在的企业业务复杂多变的情况下,使用DDD可以很好的随着业务变化不断的重构现有的领域模型,最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。阅读全文
posted @ 2014-08-30 20:45 王清培 阅读(2939) 评论(26) 编辑
摘要: 要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意,而不是胡子眉毛一把抓。现在有一个现象是什么呢,项目的结构从表面上看是很不错,层分的很合理,其实对业务系统来说也就那么几种层设计方法,但是现在很多项目的逻辑架构的设计不是理想,有很多概念大家并不是很了解,当然也许每个人对技术的追求不同罢了。不管你追求不追求,事实我们还是要去往正确的方向努力才对的。阅读全文
posted @ 2014-08-25 20:58 王清培 阅读(3109) 评论(13) 编辑
摘要: 接触分层架构有段时间了,从刚开始的朦朦胧胧的理解到现在有一定深度的研究后,觉得有必要将自己的研究成果分享出来给大家,互相学习,也是对自己的一个总结。 我们每天面对的项目结构可以说几乎都是分层结构的,或者是基于传统三层架构演变过来的类似的分层结构,少不了业务层、数据层,这两个层是比较重要的设计点,看似这两个层是互相独立的,但是这两个层如何设计真的还有很多比较微妙的地方,本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。阅读全文
posted @ 2014-08-19 21:24 王清培 阅读(4851) 评论(15) 编辑