九卷技术录

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

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

本文系统介绍了SOA架构和微服务架构的发展历程与核心特点。SOA（面向服务架构）作为企业级解决方案出现，通过ESB总线实现服务集成，解决了单体架构的扩展性和复用性问题，但存在ESB复杂度高、部署困难等局限。微服务架构则在SOA基础上进一步细化服务粒度，采用轻量级通信协议，实现服务自治和独立部署，配合容器化、DevOps等技术提升系统灵活性。二者在服务粒度、通信机制、技术栈等方面存在显著差异，但都遵循服务化思想。微服务可视为SOA在云计算时代的演进，更适应快速迭代的互联网应用场景。文章还提供了两种架构的详细对

微服务拆分指南：原则、时机与方法 微服务架构的演进是业务发展的必然趋势，但拆分需要遵循科学原则和方法。文章总结了微服务拆分的六大原则：单一职责、高内聚低耦合、单向依赖、数据库隔离、康威定律和演进式原则。拆分时机需综合考量业务阶段、复杂度、团队规模等因素。拆分方法包括业务功能分析、DDD领域驱动设计等维度，特别介绍了事件风暴等业务建模方法。文章强调微服务拆分应循序渐进，避免过度拆分带来的复杂度，并建议从非核心功能开始实践。微服务架构虽优势明显，但需根据实际业务需求谨慎选择。

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

介绍几种 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

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

本文探讨了企业实施微服务的前提条件和需要思考的关键问题。首先指出微服务通常由单体架构演进而来，建议根据业务复杂度和交付需求判断转型时机，当单体应用出现研发效率下降、交付延迟等问题时可考虑转型。文章强调组织架构需配合微服务进行调整，建议采用跨职能小团队模式。同时，基础设施建设（如CI/CD自动化流程）是重要支撑。对于微服务改造策略，推荐从小范围或边缘项目开始试点，逐步推进而非完全重构。总体而言，微服务转型需要综合考虑业务需求、组织适配和技术准备等多方面因素。

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