响应式编程中Mono和Flux的理解
|
往往最终演进的路线与企业的组织结构有关，也就是康威定律，一个系统的技术边界反映组织的结构。业界常见的是两种情况： A 吞并 B，B 与 A 一致，从例子上来讲就是基本公用一套(维度为公司/事业部/业务组级别，与企业情况有关)。 A，B 均独立发展，从例子上来讲就是均独立搭建，各管各，偶尔互相触碰边界，又或是在公开分享暗中切磋。 显然，这其中利与弊就要各自判断了，多少厂内部有多少个框架，也有血汗厂基本一统江湖的，可能做基础架构适配的小伙伴会比较有感触，不同框架的 Header 规范不一样，这样子即使是 Mesh 也避免不了一顿 if else。 更甚的是，在类似服务发现/注册、限流熔断、基础拦截器，各类 SDK 同个厂的每个内部框架都重现实现一遍。美其名曰框架支持了这些，就允许让他上，但这样子怕是在未来又造成了新的一波技术债务。 同时框架维护者，是有可能离职跳槽到别家去的，这在前端届也层出不穷，带着修炼好的真经走了，留下一个没有人维护的组内框架，这时候只能硬着头皮找 B/C 角来接受，顶上来的人指不定思想还不一样。 这单从公司层面来讲，是一个巨大的伤害，长远来看着实是灾难。 总结 在本文中，主体分为了 “开天辟地” 和 “大众创新” 两块内容，理想是丰满的，而现实怕是很骨感。微服务是一把双刃剑，带来好处的同时往往也带来了反面，架构的复杂度很难预知，因此本质上需要一个基架团队不忘初心，持续发现，持续解决问题。
但不论如何，及早的把主力语言、基本技术栈均基本统一起来，做好产品闭环，会是一个很好的方向。 至此，就可以通过结合基础平台(例如：CI/CD)实现流程上的标准化控制，成为一个提效好帮手。 大众创新 但，一切都有 “开天辟地” 那么顺利吗。实际上并不，在很多的公司中，大多数是在不同的时间阶段在不同的团队同时进行了多个开天辟地。 更具现化来讲，就是在一家公司内，不同的团队里做出了多种基础工具和基础框架。更要命的是，他们几家的规范可能还不大一样。例如：框架在 gRPC 错误码的规范处理上的差异：
又或是 HTTP 状态码的差异：
粗略一看，单单在应用错误码/状态码这一件事情上，就能够玩出花样。而这件事又会导致各种问题，例如在监控平台上，因为不同团队所定义的状态码规范不一样，就会导致连基本的监控可用性都会有问题。
像是有的小伙伴会把业务错误码放在 grpc-status 属性中，而在标准 gRPC 的规范中 grpc-status 是和 HTTP Status Code 一样有特定状态码映射的。这时候就会让监控告警系统十分难做，通用的告警规则到底是以哪份状态码为准? （编辑：平顶山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
