随笔分类 - 微服务
微服务
摘要：12.1微服务的原则 我们在第2章讨论过，微服务原则可以发挥什么样的作用。它们主要描述了该如何做，以 及为什么应该这样做的问题。这些原则可以帮助我们在构建系统时做出各种决定。你绝对 应该定义自己的原则，但微服务的一些关键原则，如图12-1总结的，我认为值得在这里洋 述。这些原则将帮助我们，创建出一系
阅读全文
摘要：扩展无状态的微服务是相对简单的。但如果我们把数据存储在一个数据库呢？我们也需要 知道如何扩展数据库。不同类型的数据库会提供不同形式的扩展，理解哪种形式最适合你 的使用场景，将确保从一开始你就选择了正确的数据库技术。 11.8.1服务的可用性和数据的持久性 更直接地说，重要的是你要区分服务的可用性和数
阅读全文
摘要：11.1故障无处不在 我们知道事情可能会出错，硬盘可能会损坏，软件可能会崩溃。任何读过“分布式计算 的故障” (https://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)的人都会告诉 你，网络也是不可靠的。我们可以尽力尝试去限制
阅读全文
摘要：数据加密是一种责任，尤其当它是敏感数据时。希望我们已经做了可以做的一切，以确保 攻击者不能攻破我们的网络，也不能攻破我们的应用程序或操作系统，然后近距离访问底 层数据。然而，我们需要做好准备，万一他们真的攻破了，我们该怎么办。深度防御非常 关键。 在许多有名的安全漏洞中，都发生了静态数据被攻击者获取
阅读全文
摘要：到目前为止，本书大部分的内容集中在向细粒度架构迈进时所面临的技术挑战。但除此之 外，我们也需要考虑组织方面的问题。在这一章，我们将了解到忽略公司的组织结构会带 来什么样的危险。 我们的行业还很年轻，它似乎在不断地重塑自己。不过，一些关键定律还是经受住了时间 的考验。例如摩尔定律，它表示集成电路上可容
阅读全文
摘要：正如我之前所展示的，将系统拆分成更小的、细粒度的微服务会带来很多好处。然而，它 也增加了生产系统的监控复杂性。在本章中，我将带大家看看细粒度的系统在系统监控和 定位问题上所面临的挑战，同时还会介绍一些应对方法，让鱼和熊掌兼得！ 我们现在有多个服务需要监控，有多个日志需要筛选，多个地方有可能因为网络延
阅读全文
摘要：我们需要考虑，在数据从一个点到另一个点的传输过程中，如何保护它们，也需要考虑在 其他情况下如何进行保护。我们需要考虑底层操作系统及网络的安全。有太多需要考虑的 点，有太多可以做的事情！那到底需要多安全呢？我们如何知道什么是足够安全呢？ 我们还需要考虑人的因素。谁在使用我们的系统，他又会做些什么？而这
阅读全文
摘要：7.1测试类型 作为一名顾问，我喜欢使用形式各异的象限来对世界进行分类。起初，我以为这本书不会 有这样的象限。幸运的是，Brian Marick想出了一个非常棒的分类测试体系，恰好就是用 象限的方式。图7-1展示了 Lisa Crispin和Janet Gregory在《敏捷软件测试》一书中，用来
阅读全文
摘要：使用之前所提到的端到端测试，我们试图解决的关键问题是什么？是试图确保部署新的服 务到生产环境后，变更不会破坏新服务的消费者。有一种不需要使用真正的消费者也能达 到同样目的的方式，它就是CDC (Consumer-Driven Contract,消费者驱动的契约）。 当使用CDC时，我们会定义服务（或
阅读全文
摘要：很早之前，就有关于“每台机器（machine)应该有多少个服务”的讨论。在我们继续之 前，应该找一个比“机器”更好的术语。在前虚拟化时代，单个运行操作系统的主机与底 层物理基础设施之间的映射形式有很多种。因此，我倾向于使用“主机”（host)这个词来 做通用的隔离单元，也就是能够运行服务的一个操作系
阅读全文
摘要：其实，对我们来说知道订单被捕获并被处理就足够了，因为可以后面再对仓库的提取表做 一次插人操作。我们可以把这部分操作放在一个队列或者日志文件中，之后再尝试对其进 行触发。对于某些操作来说这是合理的，但要保证重试能够修复这个问题。 很多地方会把这种形式叫作最终一致性。相对于使用事务来保证系统处于一致的状
阅读全文
摘要：你真的在做Cl吗 我猜你很有可能正在组织内使用持续集成。如果没有的话，你应该开始这么做，因为这个 关键实践允许我们更快速、更容易地修改代码。如果没有持续集成，向微服务架构进行转 型就会非常痛苦。即便如此，很多宣称自己在做CI的团队并没有真正在做。他们认为使 用了 ci工具就算是采用了 ci这个实践，
阅读全文
摘要：论过了。然后，尝试理解这个单块系统能够被映射到哪些限界上下文中。假设一开始我们 识别出这个单块后台系统包含以下四个上下文。 •产品目录 与正在销售的商品相关的元数据。 •财务 账户、支付、退款等项目的报告。 • 仓库 -分发客户订单、处理退货、管理库存等。 • 推荐 该系统的算法正在申请专利。它是革
阅读全文
摘要：前面提到的那些选择各自都有其适用的范围。一个组织会选择基于片段组装的方式来构建 网站，但对于移动应用来说，BFF可能是更好的方式。关键是要保持底层服务能力的内聚 性。比如，预定音乐和改变客户信息的逻辑应该处在相应的服务中，避免这些逻辑在系统中到处散布。将太多的逻辑放入到刚才提到的那种中间层中是一个常
阅读全文
摘要：4.8实现基于事件的异步协作方式 前面讨论了一些与请求/响应模式相关的技术。那么基干事件的异步通信呢？ 4.8.1技术选择 主要有两个部分需要考虑：微服务发布事件机制和消费者接收事件机制。 传统上来说，像RabbitMQ这样的消息代理能够处理上述两个方面的问题。生产者 (producer)使用API
阅读全文
摘要：由于服务端使用标准文本形式的响应，所以客户端可以很灵活地对资源进行使用，而基于 HTTP的REST能够提供多种不同的响应形式。到目前为止我们看到的例子都是XML的， 但事实上目前JSON更加流行。 JSON无论从形式上还是从使用方法上来说都更简单。有些支持者认为，相比XML， JSON的内容更加紧凑
阅读全文
摘要：3.2什么样的服务是好服务 在MusicCorp的团队为了把八轨带（eight track tape)递送到所有人手中而开始辛苦工作、 创建一个又一个的服务之前，让我们先缓缓，讨论一些很重要的基本原则。什么是好的服 务？如果你曾经尝试过SOA并且失败了，大概就知道我下一步要说什么了。不过万一你 没那
阅读全文
摘要：在我看来，集成是微服务相关技术中最重要的一个。做得好的话，你的微服务可以保持自 治性，你也可以独立地修改和发布它们；但做得不好的话会带来灾难。希望本章能够帮助 你在微服务之旅中，避免曾经在SOA中遇到的那些问题。 4.1寻找理想的集成技术 微服务之间通信方式的选择非常多样化，但哪个是正确的呢？ SO
阅读全文
摘要：本系列的文章是自己在边学习购买的书籍《微服务设计》时，边记录下来的，用于加深学习效果和以后的回顾，如若侵权，请告知，我会及时删除。
阅读全文
摘要：2.3分区 前面我们将架构师比作城市规划师，那么在这个比喻里面，区域的概念对应的是什么呢？ 它们应该是我们的服务边界，或者是一些粗粒度的服务群组。作为架构师，不应该过多关 注每个区域内发生的事情，而应该多关注区域之间的事情。这意味着我们应该考虑不同的 服务之间如何交互，或者说保证我们能够对整个系统的
阅读全文
浙公网安备 33010602011771号