55 Matching Annotations
  1. Oct 2023
  2. Dec 2022
    1. 没用微服务,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" } }
  3. Aug 2022
    1. 比如不需要交互的离线大规模计算,又比如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等,都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。

      无服务适用范围

    2. 反对 ESB、BPM 和 SOAP 等复杂的通讯机制

      比较关键

    3. 通过服务来实现独立自治的组件

      那么就需要远程调用方式提供功能

    4. soa和微服务的区别: https://www.cnblogs.com/xuwc/p/13989081.html

  4. Jul 2022
  5. May 2022
  6. Apr 2022
    1. 微服务与单体架构最显著的区别在于,单体应用程序只是单个应用程序,而微服务则是许多小的应用程序协同工作;

      微服务与单体结构,最显著的区别在于:单体应用程序只是单个应用程序,而微服务则是许多小的应用程序协同工作。

      单体应用程序是单个应用程序; 微服务则是许多小的应用程序协同工作;

    1. 在整体工风格中,组件在进程内执行,进程间的消息通信通常通过调用方法或者回调函数。从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用,产生的大量的不可靠通信。因此,你需要把粗粒度的方法成更加细粒度的通信

      应用构建,在整体风格中,组件在进程内执行,进程间的消息通信通常通过调用方法或回调函数。 从整体式风格到微服务框架,最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用,产生大量的不可靠通信。因此,你需要把粗粒度的方法,换成更加细粒度的通信。

      问题:从调用角度来看,函数或方法,难道比 API 通信,更细粒度吗?

    2. 微服务架构也使用组件库,但是它把软件拆分成服务,并认为这是主要的组织形式。我们把 组件库定义为程序中相互关系、并使用内存中调用的组件,把 服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。(这种定义的方式与其它面向对象程序中服务对象的概念是不一样的。)     把服务当成组件(而不是组件库)一个主要的原因是服务可以独立的部署。 如果你的应用由多个组件库组成并跑在一个进程中,那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用,你可以想像的到每个服务的变更仅需要发布相应的服务。 当然,这也不是绝对的,比如导致服务接口的变更的更新就需要相应服务的变化,但优秀微服务构架,会尽量避免这种服务间的耦合并完善服务的交互接口。     把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明,让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用,这个问题就很容易解决了。     使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能,而且远程的API比较粗糙,难以使用。如果由于对组件的职责进行变更,影响到跨进程间的交互,那么这操作起来也比较困难。     第一个可能的特性,我们看到每个服务是运行在独立的进程上的。注意,这只是第一个可能的特性。服务也可以由多个进程组成,它们是同时开发和部署的,例如服务可能用到一个应用进制和一种数据禀。

      微服务架构,是把软件拆分成服务,并认为这是主要的组织形式。当然,微服务架构也使用组件库。

      我们把组件库定义为程序中相互关系,并使用内存中调用的组件,把服务定义为进程间调用。如,Web 请求服务或远程调用来相互通信的组件。

      把服务当成组件,而不是组件库,主要的原因是服务可以独立部署。

      如果应用由多组件组成,并跑在一个进程中,那任何组件的变更,都将导致整体应用的重新发布。但如果由许多服务构成的应用,每个服务的变更仅需发布相应的服务。

      这并不是绝对的,比如:导致服务接口变更的更新,就需要相应服务的变化。应尽量避免这种服务间的耦合,并完善服务的交互接口。

      服务当成组件的另一考虑是拥有更清晰的接口。服务是通过明确的远程接口调用。

      远程调用,比进程内部调用更消耗性能。

    3. 组件与服务     自从我们从事软件行业以来,一直希望能够构建由组件组成的系统,就像我们所看到的实现世界由物件构成的一样 。在过去的几十年里,我们已经看到了大部分语言平台的公共库的进行了精简,并取得可观的进展。     当我们谈论组件的时候,有可能会因为组件的不同定义引起混乱。因此我们申明,这里谈到的 组件是指软件中独立的单元,它能独立替代和独立更新。

      希望能构建由组件组成的系统,就像我们所看到的现实世界由物件构成的一样。 (大部分语言平台的公共库进行了精简) 谈论组件的时候,可能会因组件的不同定义引发混乱。 这里谈到的组件是指软件中独立的单元,它能独立替代和独立更新。 (组件,软件中独立的单元,它能独立替代和独立更新。)

    4. 以服务构建应用。 因为服务可以独立部署、独立扩展,服务也可以提供模块化的边界,并且不同的使用也可以使用不同的开发语言。服还可以以不同的周期进行管理。

      整体风格的系列原因,导致了微服务架构风格的出现——以服务构建应用。

      服务可以独立部署、独立扩展。 服务也可提供模块化的边界。(模块化的边界) 不同的服务,可使用不同的开发语言。 不同的服务可以不同的周期进行管理。

    5. 整体风格 :即把一个完整的应用当成一开发单元。 企业应用通常包含三个部分:客户端界面(由HTML、Javascript组成,使用浏览器进行访问)、数据库(由许多的表组件构成一个通用的、相互关联的数据管理系统)、服务端应用。服务端应用处理HTTP请求、执行领域逻辑、检索并更新数据库中的数据、使用适当的HTML视图发送给客户端。服务端应用是完整的 ---- 由单一的逻辑层次执行。系统中任务变更都会导到服务端的应用重新编辑并发布一个新的版本。     这样的整体服务是这样的构建系统的很自然的方式。虽然利用开发语基础特性会把应用封装成类、函数、命名空间,但是业务中所有逻辑都要在单一的进程中处理完成。 在某些场景中,开发者可能在的笔计本中开发、测试应用,然后利用部署通道来保证经过正常测试、发布的修改内容正确的发布的产品中。也可以使用横向扩展,通过负载均横系统将事个应用部署到多台服务器上。     整体风格的应用也是相当成功的,但是越来越多的人感觉到有点不妥,特别是在云中进行应用的发布 时。变更发布周期被绑定了 ---- 原来可以划分成小的应用、小的需要的变更,需要统一的进行编译和发布。 随着时间的推移,人们通常难于维护一种优美的模块化的结构,使得一个模块的变更很难不会影响到其它的模块。进行扩展,也需要进行整体的扩展,而不能根据进行部分的扩展。

      整体风格:把一个完整的应用,当成一开发单元。

      企业应用,通常包含三部分: 1》客户端界面(由 HTML、JavaScript组成,使用浏览器进行访问)、 2》数据库(由许多的表组件构成一个通用的、相互关联的数据管理系统)、 3》服务端应用。


      服务端应用处理 HTTP 请求、执行领域逻辑、检索并更新数据库中的数据、使用恰当的 HTML 视图发送给客户端。 服务端应用是完整的——由单一的逻辑层次执行。 系统中,任务变更都会导致服务端的应用重新编辑,并发布一个新的版本。

      整体风格,利用开发语言基础特性把应用封装成类、函数、命名空间,但业务中所有逻辑都是要在单一的进程中处理完成。

      开发、测试应用,利用部署通道保证经过正常测试,发布修改的内容。

      横向扩展,通过负载均衡系统,将多个应用部署到多台服务器上。

      整体风格,在云中进行应用发布时,变更发布周期被绑定了。原本可划分成小的应用、小的需求的变更,需要统一的进行编译和发布。

      人们难于维护一种优美的模块化的结构,使得一个模块的变更不会影响到其他的模块。

      要进行扩展,也需进行整体的扩展,而不能根据进行部分扩展。

    6. “微服务架构”一词在过去几年里广泛的传播,它用于描述一种让分布式的应用软件系统进行独立演进的特别的设计方法。

      微服务架构,用于描述一种让分布式的应用软件系统进行独立演进的特别的设计方法。 它并没有非常准确的定义,但在业务模块、自动部署、端对端的整合、多语言支持和数据管理的分布式控制上,有着显著特征。

  7. Feb 2021
    1. PaperWeekly 每周会分享 N 篇当下最流行、最有趣的自然语言处理、机器学习、深度学习主题相关的研究论文,旨在用最精炼的话说明白 Paper 的贡献和创新。

    1. The Economist Espresso 是经济学人推出的新闻晨报服务。每天早晨推送 5 篇精华文章供你阅读,犹如清晨咖啡一般,让你习惯自然享用。

    1. 一个邮件订阅服务, 通过 Wikimedia Tool Labs 检索每周更新条目, 利用 MailChimp 每周五通过邮件推送上一周被编辑和讨论次数最多的 Wikipedia 条目列表。内容包括:过去一周 20 大热门条目、过去一周新建的 10 条最活跃条目、过去一周最活跃的讨论以及过去一周 Wikipedia 被编辑的次数统计。

  8. Dec 2020
  9. May 2018