微服务不是银弹
发表于
本文字数：
1.2k
阅读时长 ≈
4 分钟
Fred Brooks 在他的两本著作《没有银弹：软件工程的本质性与附属性工作》和《人月神话：软件项目管理之道》里都反复强调着一个观点：“软件研发中任何一项技术、方法、架构都不可能是银弹”。
目的：为什么选择微服务
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
外部因素
- 没有什么技术能包打天下。考虑到技术异构选择微服务是没有选择、无可避免的。
- 人才储备。选择微服务能使高水平开发、运维人员来实现关键业务服务，外围功能交给非核心人员，以便保证系统整体的稳定和局部的容错、自愈与快速迭代。
- 甲方要求。甲方招投标文件技术规范明文要求。
- …
内部因素
- 快速变化业务的自主选择。微服务让系统有更好的可观测性、快速迭代和自愈能力。
- 大规模的、业务复杂的、历史包袱沉重的单体系统会自然向微服务演进。
- …
前提：微服务的条件
康威定律
决策者与执行者都能意识到康威定律在软件设计中的关键作用。康威定律的核心观点是“沟通决定设计”，其社会学和管理学的规律决定了假如产品和组织能够经受住市场竞争，长期发展的话，最终都会自发地调整成组织与产品互相匹配的状态。
为了推进软件架构的微服务化而配合地调整组织架构，通常不是一件容易的事情。因为所有的技术上的决策实际都是政治上的决策。解决这个问题不仅需要执行者有良好的社交能力，还需要更上层的决策者充分理解架构演变同步调整组织结构的必要性，为微服务化打破局部的利益藩篱。
技术专家
开发业务的普通程序员可以不去深究跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展这些系统性的问题，它们被隐藏于软件架构的最底层，被掩埋在基础设施之下。靠谱的软件架构应该要由深刻理解微服务的技术专家来设计建造，健壮的基础设施也离不开有经验的运维专家的持续运维。
如果整个团队中缺乏能够在微服务架构中撑起系统主干的技术和运维专家，强行进行微服务化并不会有任何好处，至少收益不足以抵消复杂性增加而导致的成本。
一个残忍的真相是：软件架构的趋势将导致开发者的分层，从如今所有开发者都普遍被认为是“高智商人群”的状态，转变为大部分工业化软件生产工人加上小部分软件设计专家的金字塔结构。
自治和监控
由于微服务数量多、发布快，迅速升级和回滚的自动化是必要的，但监控对于任何一个系统都需要。
微服务自动化的最终目的是构筑一个可持续的生态系统，现阶段仍然是一个过于理想化的目标。建设微服务的不同时期，由不同程度的人力去参与运维完全可行的，只要满足与系统规模和目标相匹配的自动化能力。只有朝着这个目标去发展自动化与监控度量，避免自动化与度量监控反过来成为人与系统的负担。
复杂性
架构是演进式设计的，对于小型系统，单体架构就是最好的架构。复杂度的提升自然而然过渡到微服务架构中。
边界：微服务的粒度
下界
微服务粒度的下界是它至少应满足独立，内聚，完备三个特征。
独立：独立发布、独立部署、独立运行与独立测试。
内聚：强相关的功能与数据在同一个服务中处理。
完备：个服务包含至少一项业务实体与对应的完整操作。
上界
微服务粒度的上界是一个 2 Pizza Team，能够在一个研发周期内完成的全部需求范围。
这是由于邓巴数的存在。
参考
成为问题解决者
发表于
本文字数：
786
阅读时长 ≈
3 分钟
我的伙伴：
截止到 2023 年 6 月，我经历了 1 年实习，不到 2 年的工作，完成了一些里程碑。编写过 Java、Dart、Golang、JavaScript 等语言程序。研究了 Spring、Gin 后端框架。尝试了 React、Vue 前端框架和 Flutter 跨平台框架。对于需求分析与整理、架构设计与落地、编程规范与重构、Codebase、DevOps 等研发流程，也积累了一些思考。B 站中， 上传 11 支技术视频，获得 5000+ 播放量和 100+ 粉丝。个人博客中，发表 51 篇技术文章，42 千的字数和 150 分钟的阅读时长。Github 中，提交 265 次代码，收获 3 个 star 和 5 次 fork。
如今，大厂小厂纷纷裁员，中年失业屡见不鲜，寒气的的确确传递给每位从业者。古人说：“不以物喜，不以己悲”。宁向东教授说：“低谷的时候，多读书，多做准备，冷静判断时势，对自己有信心”。
我崇拜 Linus Torvalds、Jeff Dean 这样用技术改变世界的天才，钦佩 Rod Johnson、Evan You 这样技术解放开发者的大佬，佩服对技术有追求的同行们。对我来说，单纯的几行漂亮代码什么也做不了。技术要赋能业务，业务成功体现技术价值。技术也可赋能商业，商业是更宏大的命题。
一切以解决问题为中心
目前，衡量自己是否成功的一个最基本的标准，就在于是否彻底解决了问题。
作为公司的一员，问题直接来源于公司业务，解决业务问题的能力越强，个人就越有竞争力。帮助公司占领市场领导地位，公司才能有更高的利润，个人才能有更高的收入。
基于此长期价值，我将展示自己的做事方法，以便各位判断我们是否是同路人：
- 全力解决 BUG；
- 需求分析有输出，文档清晰后再编码；
- 谦逊，爱护同事；
- 多分享，有输出；
- 与优秀者共事；
- 接触社区，融入社区，反馈社区；
- 先开始，在学习；
- 关注商业，关注产业，关注盈利；
我不敢宣称自己的方法是“正确”，但至少这是我的做事哲学。如果自己都不清楚如何去做，那只能被解释为混日子。在此基础上，写下自己对未来的展望。
工作要求
对自己负责的需求点、模块和项目，需要详细的需求分析，架构设计和实现要主动调研主流实现方案，最后进行编码。产生的 BUG 要第一时间解决，小步快跑，快速迭代。
不属于自己的负责范畴的内容，以解决问题为目的。不抱怨，不分心。
参与社区
积极参与行业会议，以便熟悉行业主流的技术方案和选型；
拥抱社区，尝试解决社区问题，贡献代码；
积极分享
视频、文章、问答等各种方式，分享不限于技术的观点。
最简明好用的 BP 撰写指南
发表于
本文字数：
540
阅读时长 ≈
2 分钟
向投资人讲解自己的创业项目，本质上是一次推销。一次精彩的演讲必定是一篇引人入胜的故事，故事创造连接，产生触动，改变观念，进而施加影响。商业计划书（BP）就是创业者第一次对外讲故事的载体。
企业是做什么的？
用一个陈述句来定义自己的公司，讲清楚自己的企业是做什么的。
为什么要做？
市场发生了什么样的改变，这些为你创造了什么样的机会。
为什么你的技术、业务和解决方案，在此之前并没有建立起来？
目标客户面临的具体痛点，以及为什么当下的解决方案并不能解决它。
如果你的产品成功，世界会变成什么样子。
做成什么样？
清晰地表达产品的特性和架构，解释产品是如何工作。
你的产品如何解决痛点。
你的护城河。
市场营销和变现策略。
目前是什么阶段？
解释当前产品的现状，如客户获取、使用和留存、单位经济效益（Unit Economics）和损益情况（P&L）。
解释为何你的产品能够脱颖而出。
下一阶段的目标是？
公司和产品接下来的 5 年规划。
市场有多大，增长有多快，处于什么样的位置。
如何分配利润。
竞争对手是谁，如何赢得竞争。
你的伙伴是谁？
讲述主要团队成员，和二级管理团队。
总结
每个要点 3 - 5 张幻灯片，突出重点、关键点和记忆点。
分享你的愿景；阐述你正在解决的问题；客户成功是什么样的；
通过解释如何创造价值（产品策略），如何传递价值（市场策略），如何获取价值（变现策略），如何获得1亿美元的收入以及围绕业务的关键护城河来谈论企业和商业模式。
展示运营指标（获取、使用、留存和转换）、财务数据、产品指标。