on-demand materials era
「按需材料时代」是 cusp.ai 对未来的命名。类比：就像云计算把算力从实物变成服务，材料也可以从「发现+制造」变成「按需生成」。这个概念如果成立，意味着供应链、国防、半导体等行业的原材料瓶颈将从物理约束变成算法问题。
57 Matching Annotations
- Jun 2026
-
www.cusp.ai www.cusp.ai
-
cloud.google.com cloud.google.com
-
The answer to this problem isn't another knowledge service. You need a format
这是整篇文章最关键的一句话，也是OKF设计哲学的核心。解决知识碎片化的直觉反应是再建一个服务——更好的数据目录、更全的知识图谱。但Google的判断是：问题不是缺少一个中心化服务，而是缺少一个让所有人可以互操作的格式。这个区别至关重要：格式是公共品，服务是护城河。OKF选择做前者，意味着它的价值随着采用者数量增长，而不是随着某一家厂商的功能迭代。
-
- Oct 2023
-
www.infoq.cn www.infoq.cn
-
服务治理就是对服务复杂度膨胀问题的管控及管理
Tags
Annotators
URL
-
- Dec 2022
-
blog.csdn.net blog.csdn.net
-
Eureka控制台相关介绍及自我保护机制解说
-
-
mp.weixin.qq.com mp.weixin.qq.com
-
Spring Cloud Gateway + Jwt + Oauth2 实现网关的鉴权操作
Tags
Annotators
URL
-
-
colobu.com colobu.com
-
没用微服务，Shopify的单体程序居然支撑了127万/秒的请求？ function show_answer(btn, x) { if (btn.value === "显示答案") { btn.value = "隐藏答案" } else { btn.value = "显示答案" } var as = document.getElementById(x); if (as.style.display === "none") { as.style.display = "block" } else { as.style.display = "none" } }
-
-
www.zhihu.com www.zhihu.com
-
在以TCP为连接方式的服务器中，为什么在服务端设计当中需要考虑心跳？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
分布式服务架构与微服务架构概念的区别与联系是怎样的？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
微服务架构中是否应该把诸如redis、mq之类的中间件也封装成一个服务？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
Spring Boot + MyBatis 如何优雅的实现数据库读写分离？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
前端为什么不设些缓存服务器？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
2017年，Web 后端出现了哪些新的思想和技术？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
nacos 一个服务中如何注册多个端口?
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
JAVA大军，开始把目光从spring cloud转向k8s甚至k8s+istio了么？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
为何说spring cloud适合中小型项目，而不适合大型项目？
-
-
www.zhihu.com www.zhihu.com
-
要达到什么样的规模才适合分布式/微服务架构?
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
Kubernetes 可以完全替代 Spring Cloud 吗？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
为什么游戏公司的server不愿意微服务化？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
2021年，如果选型一个Node.js的web server框架，你会选择什么？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
微服务架构中如何解决连表查询的问题？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
www.zhihu.com www.zhihu.com
-
HTTPS 要比 HTTP 多用多少服务器资源？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
异步io有什么优势？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
服务器集群负载均衡原理？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
有哪些优秀且免费的云存储服务？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
搭建家庭 NAS 服务器有什么好方案？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
既然一个 IP 地址可以被多个域名绑定，那么服务端是如何区分各个域名的?
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
自建视频网站服务器需要多大的性能？
-
-
www.zhihu.com www.zhihu.com
-
有哪些轻量级web服务器？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
如何理解即将动工的Dubbo 3.0？
-
-
www.zhihu.com www.zhihu.com
-
学习Ajax，关于XMLHttpRequest对象是怎么从后台和服务器交换数据的不太理解？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
APP IM 服务器设计思路？
-
-
www.zhihu.com www.zhihu.com
-
如何深入理解多进程，多线程，非阻塞/异步IO(callback) 以及Coroutine模型？
Tags
Annotators
URL
-
-
www.zhihu.com www.zhihu.com
-
常见的网站服务器架构有哪些？
-
-
www.zhihu.com www.zhihu.com
-
MOBA类游戏是如何解决网络延迟同步的？
-
-
www.zhihu.com www.zhihu.com
-
端游、手游服务端常用的架构是什么样的？
-
- Aug 2022
-
www.freitag.ch www.freitag.ch
-
time.geekbang.org time.geekbang.org
-
比如不需要交互的离线大规模计算，又比如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等，都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。
无服务适用范围
-
反对 ESB、BPM 和 SOAP 等复杂的通讯机制
比较关键
-
通过服务来实现独立自治的组件
那么就需要远程调用方式提供功能
-
soa和微服务的区别： https://www.cnblogs.com/xuwc/p/13989081.html
Tags
Annotators
URL
-
- Jul 2022
-
time.geekbang.org time.geekbang.org极客时间1
-
不同项目可复用某些微服务
好多
Tags
Annotators
URL
-
- May 2022
-
www.envoyproxy.io www.envoyproxy.io
-
Egress listeners
-
Ingress listeners
-
- Apr 2022
-
www.yuque.com www.yuque.com
-
微服务与单体架构最显著的区别在于，单体应用程序只是单个应用程序，而微服务则是许多小的应用程序协同工作；
微服务与单体结构，最显著的区别在于：单体应用程序只是单个应用程序，而微服务则是许多小的应用程序协同工作。
单体应用程序是单个应用程序； 微服务则是许多小的应用程序协同工作；
Tags
Annotators
URL
-
-
blog.csdn.net blog.csdn.net
-
在整体工风格中，组件在进程内执行，进程间的消息通信通常通过调用方法或者回调函数。从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加细粒度的通信
应用构建，在整体风格中，组件在进程内执行，进程间的消息通信通常通过调用方法或回调函数。 从整体式风格到微服务框架，最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生大量的不可靠通信。因此，你需要把粗粒度的方法，换成更加细粒度的通信。
问题：从调用角度来看，函数或方法，难道比 API 通信，更细粒度吗？
-
微服务架构也使用组件库，但是它把软件拆分成服务，并认为这是主要的组织形式。我们把 组件库定义为程序中相互关系、并使用内存中调用的组件，把 服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。（这种定义的方式与其它面向对象程序中服务对象的概念是不一样的。） 把服务当成组件（而不是组件库）一个主要的原因是服务可以独立的部署。 如果你的应用由多个组件库组成并跑在一个进程中，那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用，你可以想像的到每个服务的变更仅需要发布相应的服务。 当然，这也不是绝对的，比如导致服务接口的变更的更新就需要相应服务的变化，但优秀微服务构架，会尽量避免这种服务间的耦合并完善服务的交互接口。 把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明，让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用，这个问题就很容易解决了。 使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能，而且远程的API比较粗糙，难以使用。如果由于对组件的职责进行变更，影响到跨进程间的交互，那么这操作起来也比较困难。 第一个可能的特性，我们看到每个服务是运行在独立的进程上的。注意，这只是第一个可能的特性。服务也可以由多个进程组成，它们是同时开发和部署的，例如服务可能用到一个应用进制和一种数据禀。
微服务架构，是把软件拆分成服务，并认为这是主要的组织形式。当然，微服务架构也使用组件库。
我们把组件库定义为程序中相互关系，并使用内存中调用的组件，把服务定义为进程间调用。如，Web 请求服务或远程调用来相互通信的组件。
把服务当成组件，而不是组件库，主要的原因是服务可以独立部署。
如果应用由多组件组成，并跑在一个进程中，那任何组件的变更，都将导致整体应用的重新发布。但如果由许多服务构成的应用，每个服务的变更仅需发布相应的服务。
这并不是绝对的，比如：导致服务接口变更的更新，就需要相应服务的变化。应尽量避免这种服务间的耦合，并完善服务的交互接口。
服务当成组件的另一考虑是拥有更清晰的接口。服务是通过明确的远程接口调用。
远程调用，比进程内部调用更消耗性能。
-
组件与服务 自从我们从事软件行业以来，一直希望能够构建由组件组成的系统，就像我们所看到的实现世界由物件构成的一样 。在过去的几十年里，我们已经看到了大部分语言平台的公共库的进行了精简，并取得可观的进展。 当我们谈论组件的时候，有可能会因为组件的不同定义引起混乱。因此我们申明，这里谈到的 组件是指软件中独立的单元，它能独立替代和独立更新。
希望能构建由组件组成的系统，就像我们所看到的现实世界由物件构成的一样。 （大部分语言平台的公共库进行了精简） 谈论组件的时候，可能会因组件的不同定义引发混乱。 这里谈到的组件是指软件中独立的单元，它能独立替代和独立更新。 （组件，软件中独立的单元，它能独立替代和独立更新。）
-
以服务构建应用。 因为服务可以独立部署、独立扩展，服务也可以提供模块化的边界，并且不同的使用也可以使用不同的开发语言。服还可以以不同的周期进行管理。
整体风格的系列原因，导致了微服务架构风格的出现——以服务构建应用。
服务可以独立部署、独立扩展。 服务也可提供模块化的边界。（模块化的边界） 不同的服务，可使用不同的开发语言。 不同的服务可以不同的周期进行管理。
-
整体风格 ：即把一个完整的应用当成一开发单元。 企业应用通常包含三个部分：客户端界面（由HTML、Javascript组成，使用浏览器进行访问）、数据库（由许多的表组件构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理HTTP请求、执行领域逻辑、检索并更新数据库中的数据、使用适当的HTML视图发送给客户端。服务端应用是完整的 ---- 由单一的逻辑层次执行。系统中任务变更都会导到服务端的应用重新编辑并发布一个新的版本。 这样的整体服务是这样的构建系统的很自然的方式。虽然利用开发语基础特性会把应用封装成类、函数、命名空间，但是业务中所有逻辑都要在单一的进程中处理完成。 在某些场景中，开发者可能在的笔计本中开发、测试应用，然后利用部署通道来保证经过正常测试、发布的修改内容正确的发布的产品中。也可以使用横向扩展，通过负载均横系统将事个应用部署到多台服务器上。 整体风格的应用也是相当成功的，但是越来越多的人感觉到有点不妥，特别是在云中进行应用的发布 时。变更发布周期被绑定了 ---- 原来可以划分成小的应用、小的需要的变更，需要统一的进行编译和发布。 随着时间的推移，人们通常难于维护一种优美的模块化的结构，使得一个模块的变更很难不会影响到其它的模块。进行扩展，也需要进行整体的扩展，而不能根据进行部分的扩展。
整体风格：把一个完整的应用，当成一开发单元。
企业应用，通常包含三部分： 1》客户端界面（由 HTML、JavaScript组成，使用浏览器进行访问）、 2》数据库（由许多的表组件构成一个通用的、相互关联的数据管理系统）、 3》服务端应用。
服务端应用处理 HTTP 请求、执行领域逻辑、检索并更新数据库中的数据、使用恰当的 HTML 视图发送给客户端。 服务端应用是完整的——由单一的逻辑层次执行。 系统中，任务变更都会导致服务端的应用重新编辑，并发布一个新的版本。
整体风格，利用开发语言基础特性把应用封装成类、函数、命名空间，但业务中所有逻辑都是要在单一的进程中处理完成。
开发、测试应用，利用部署通道保证经过正常测试，发布修改的内容。
横向扩展，通过负载均衡系统，将多个应用部署到多台服务器上。
整体风格，在云中进行应用发布时，变更发布周期被绑定了。原本可划分成小的应用、小的需求的变更，需要统一的进行编译和发布。
人们难于维护一种优美的模块化的结构，使得一个模块的变更不会影响到其他的模块。
要进行扩展，也需进行整体的扩展，而不能根据进行部分扩展。
-
“微服务架构”一词在过去几年里广泛的传播，它用于描述一种让分布式的应用软件系统进行独立演进的特别的设计方法。
微服务架构，用于描述一种让分布式的应用软件系统进行独立演进的特别的设计方法。 它并没有非常准确的定义，但在业务模块、自动部署、端对端的整合、多语言支持和数据管理的分布式控制上，有着显著特征。
-
- Feb 2021
-
www.paperweekly.site www.paperweekly.site
-
PaperWeekly 每周会分享 N 篇当下最流行、最有趣的自然语言处理、机器学习、深度学习主题相关的研究论文，旨在用最精炼的话说明白 Paper 的贡献和创新。
-
-
www.economist.com www.economist.com
-
The Economist Espresso 是经济学人推出的新闻晨报服务。每天早晨推送 5 篇精华文章供你阅读，犹如清晨咖啡一般，让你习惯自然享用。
-
-
weekly.hatnote.com weekly.hatnote.com
-
一个邮件订阅服务， 通过 Wikimedia Tool Labs 检索每周更新条目， 利用 MailChimp 每周五通过邮件推送上一周被编辑和讨论次数最多的 Wikipedia 条目列表。内容包括：过去一周 20 大热门条目、过去一周新建的 10 条最活跃条目、过去一周最活跃的讨论以及过去一周 Wikipedia 被编辑的次数统计。
-
- Dec 2020
-
github.com github.com
Tags
Annotators
URL
-
-
github.com github.com
Tags
Annotators
URL
-
- May 2018
-
Local file Local file
-
这是一个标题
-