九卷技术录

小公司需要微服务架构吗？技术架构选型应该从哪些方面来考虑？有哪些要素需要考虑？

从单体架构到微服务架构的演进历程，详细剖析，各阶段架构分解。

服务治理中的熔断器算法介绍

介绍几种 Go 开源限流算法库

微服务治理：常用限流算法总结.

为什么需要监控，除了上面说的作用外，下面对监控的作用做一些总结。化被动为主动近实时了解业务运行的健康状况提前获知业务异常情况信息并告警通知帮助定位各种异常、bug等故障为排障提供详细信息业务运营信息的统计和监控监控系统资源使用情况，保障系统稳定运行对异常情况发出告警通知，及时进行处理维基上：控制理论中的可观察性（observability）是指系统可以由其外部输出推断其其内部状态的程度。

​ （来源：https://github.com/apolloconfig/apollo/ apollo github）Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

开源的 java API 网关介绍。他们都是是构建在 Spring 生态之上，包括 Spring5、Spring2 和 Project Reactor(Spring WebFlux)。Spring WebFlux 框架底层使用了 Reactor 模式高性能通信框架 Netty等等，更多详情请看文章。

微服务技术体系一文中又提到过一些开源网关软件。这次再来详细介绍下开源 API 网关软件。比如kong，openresty，apisix等等。

对于上面图 1 的一个请求响应路径，怎么定义、怎么能实现分布式追踪呢？简单实现：为服务器每一次的发送和接收请求来收集追踪标识（message identifiers）和时间戳（timestamped events）。从入口开始发起 Request 的请求者（图 1 中的 RequestX），与这个请求者相关的信息都要关联上，并记录下来分析链路关系，有什么好的方案呢？2 种方案：黑盒（black-box）和基于标注（annotation-based）的监控方案。

1.服务注册2.服务发现3.服务下线处理4.服务健康检查。

微服务架构特点：每个微服务是独立的，团队可以独立开发，独立测试，独立部署，服务是自治的。到了微服务架构时期，利用分治的思想把业务划分为了一个一个小的服务，每个开发团队独立负责几个微服务的业务，这时候团队组成人员也要进行相应的调整，以适应微服务架构的开发。我们要把以前那种中心化的组织架构，改成去中心化的组织，每个团队可以独立完成一个微服务业务的开发上线，即设计，开发，测试，部署，上线服务。原先那种职能型的团队，变成了跨职能的小团队，这种团队和微服务架构对齐，实现团队的独立和自治，实现一体化开发上线操作。

在微服务技术体系中，已经列出了构建微服务架构所需要的技术。这篇文章只是列出了构建微服务所需要的技术，是微服务所需技术的整体介绍。但是并没有说明构建一个微服务的具体工作是怎么做的？需要做哪些事情？这一篇文章就来说说这些问题。如何定义一个服务？而且各种语言都通用的，各种开发都可以使用的一种语言。这就是 IDL。在微服务中，最简单的一个请求模型就是：请求 应答。那怎么定义请求部分的数据格式，返回部分的数据格式？其实“巨人”已经给我们准备好了，那就是和thrift。

微服务架构使用场景的分析，单体架构和微服务架构各方面的对比，看看你在选型微服务时候，最看中哪些要素，然后选择你需要的架构设计

微服务架构学习系列文章：微服务架构学习与思考(01)：什么是微服务？微服务的优势和劣势微服务架构学习与思考(02)：微服务实施的前提条件？有哪些问题需要思考？微服务架构学习与思考(03)：微服务总体架构图解微服务架构学习与思考(04)：微服务技术体系微服务架构学习与思考(05)：微服务架构适用场景分析一、微服务技术体系下图列出了微服务的技术体系：二、Golang微服务技术栈微服务框架go-microgo-kit国内的bilibili、好未来和斗鱼也出了一个微服务框架：k

微服务总体架构图解，用图的方式来把架构做一个概览

一、前言“地址：https://www.cnblogs.com/jiujuan/p/13284412.html前一篇文章简单分析了微服务的好处，以及会带来的问题。遇到问题并不可怕，可怕的是我们不去面对它，不去想办法解决它，逃避问题是不可能有任何进步。所以积极想办法应对问题并解决问题，才能不断的进步。前面讲了，微服务一般都是由单体演进而来，很少有业务从0就开始进行微服务开发。如果能从0就开始用微服务开发，确实是一件很好的事情，前提是你确实考虑清楚了用微服务开发适合当前的业务以及业务的发展需求。那

一、单体应用在软件开发早期阶段，大家都在一个应用系统上开发。各个业务模块之间耦合也比较紧密。软件发布也是整体发布，或者对软件进行打包发布和部署，比如java可以打包成war部署。测试也很容易，因为代码都在一起，基本不需要引用外部的关联服务。在软件开发早期，这种软件开发模式能适应业务的发展，软件应用也可以正常运行。如果你的业务发展良好，客户需求会变得越来越多，软件功能数也会随着客户的需求变多而变多。为了实现这些功能，你必须添加很多代码。而随着业务进一步发展，代码量势必也会越增越多。有可能 2 到 3年后