自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

产品级敏捷 2.0: 用户的想法与产品之间的那条最短的路径

不仅关注产品开发的效率与产品的质量, 更重视: 产品对用户的体验与价值

  • 博客(13)
  • 资源 (1)
  • 收藏
  • 关注

原创 产品为何总是做不好 (三): 会让产品走向失败的架构师

也许你的架构师, 只是个标准答案的复印机

2016-08-31 22:33:17 505

原创 产品为何总是做不好 (二): 被一群有权力没能力; 有屁股没脑袋; 的公公婆婆所挟持

在离开西安的前一晚,我又来到了,我所熟悉的那间面店、咖啡店。一碗极其简单的面、一杯什么都不加的黑咖啡,正好能让我真正的感受到那…最简单却又最原始的美味。为何简单到不行,却能让人感动到最深?

2016-08-31 22:15:33 799

原创 产品为何总是做不好 (一): 只是因为我们都太聪明了

我一直以来都并不认为,从事 IT 这一行的,会有谁不明白 Scrum, Less, SAFe 里面的思维与做法的。但为何仍常常会看见,许多连做产品的 Common Sense 都没有的场景,在我们的周遭随时的在发生?是我们太愚蠢了吗?能将 SAFe, Scrum, Less 挂在嘴边,却连做产品的 Common Sense 都没有。不是我们太愚蠢,事实上却恰恰的相反;是我们每个人

2016-08-28 11:06:46 1282

原创 微服务架构 (九): 分布式微服务下的数据一致性

微服务都拥有各自的数据库且微服务都是部署在一分布式的环境下的。所以, 微服务间要维持彼此间数据库中的数据的一致性, 便需采用:BASE – Basic Availability, Soft State, Eventual Consistency。架构师在 BASE下, 便有四种架构设计的方案, 使整体微服务架构下的相关数据从 Soft State, 经过一段时间后; 也许是几分钟, 也许是一个晚上…等等; 最终, 使得整体微服务架构下的相关数据, 达到一致性; Eventual Consisten

2016-08-21 18:15:40 7531 3

原创 微服务架构 (八): 业务驱动与团队协作微服务粒度设计: 微服务内部的世界

在 “微服务架构設計 (七): 微服务粒度设计上的核心设计原则与思考的面向” 的一文中, 探讨了从微服务外部的世界驱动微服务粒度的设计。如文中所描述, 为了保障微服务整体的性能与可靠度, 可能会设计出粒度较大的微服务, 而降低了微服务持续部署的速度。然而, 架构师也不能光只看到微服务外部的世界, 而轻忽或完全忽略了微服务内部的世界。

2016-08-20 17:45:31 2006

原创 微服务架构 (七): 微服务粒度设计上的核心设计原则与思考的面向

架构师在设计微服务时, 需把握一个核心的设计原则:微服务 “外部的世界” 远比 “内部的世界” 重要。

2016-08-19 12:58:29 5249

原创 微服务架构 (六): 微服务间的共享的管理

在微服务的架构下, 产品或许会有上百个或上千个微服务。所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (Library) 时, 则当此共享的库, 即使只是针对某个微服务做些很少量的修改, 也可能会对其他上百个或上千个微服务, 造成不可预期的影响。但在实际的项目中, 产品中的微服务又无法避免的会对某些库 (Library) 产生依赖; 共享某些库 (Library)。所以, 架构师

2016-08-18 19:16:35 4141

原创 微服务架构 (五): 获取微服务数据, 生成报表

架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Context), 数据的时效性, 性能, 可靠性与开发的复杂度间作取舍。从多个微服务取数据, 而生成报表的设计方案, 主要是参考: Enterprise Integration Patterns; Hohpe and Woolf。

2016-08-17 00:18:38 7475

原创 微服务架构 (四): 提升微服务分布式远程调用的可靠性与性能; Time Out 与 Circuit Breaker

在微服务分布式的架构下, 我们一直很努力的在可靠性与性能间, 找到一个最佳的解决方案。

2016-08-14 22:33:13 2118

原创 微服务架构 (三): 在微服务的架构中, 也许不需要 Integration Hub

在微服务的核心概念中, api layer 主要是在微服务与微服务外部的使用者界面、系统或设备之间构建 endpoint proxy 与 load balancer。所以, 在微服务的架构中,架构师规划 Integration Hub; 如: Mule,Camel, ESB…等等, 应该是个合理且正确的架构方案。但是, 在微服务的架构中, 规划所谓的 Integration Hub, 往往却

2016-08-12 00:39:55 2241

原创 协作为何如此的重要?

产品的缺陷、问题单就宛如是一面镜子;镜子里全是自己的无知、傲慢、自以为是。

2016-08-09 22:33:35 800

原创 微服务架构 (二): 从既有的架构迁移到微服务的策略

架构师应一直铭记在心:微服务正确、适当的边界上下文 (Bounded Context), 绝对是要经由不断的演进与学习而获得的; 没有标准答案, 没有一步到位的。

2016-08-09 22:14:33 1984

原创 微服务架构 (一): 微服务架构的核心概念

微服务设计是架构设计。所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程。而应该是一个考量各方因素下的一个决策的过程。所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念?

2016-08-08 22:31:34 9230

精益敏捷开发的软件架构设计

在精益敏捷开发中, 如何进行软件架构设计, 一直是个有趣的话题◦ 此份材料主要便是在探讨, 在精益敏捷开发中运用简单, 轻量级, 视觉化的工具, 使得精益敏捷开发的团队成员, 可共同的协作, 以更高效的方式, 设计出可拥抱使用者, 平台与设备变化的软件架构◦

2014-05-29

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除