微服务概览与治理详解

基本上在产品的最开始阶段，为了快速构建产品，都是单体架构，尽快我们也会按照业务划分模块，但是这个样子始终最终部署的时候还是单体式应用。

如我们早期可以使用Python 的Django快速迭代一个web应用，我们会在Django中划分不同的模块，也就是Django中的app。

而随着业务的迭代发展，项目越来越复杂，可能就会导致应用的扩展，可靠性越来越低，最终导致敏捷开发和自动化部署变得无法完成。

微服务定义

关于SOA

!! 面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

所以我们可以把微服务看做是SOA的一种实践：

• 小即是美：小的服务代码少，bug也少，易于测试，易于维护，也更容易不断迭代完善。
• 单一职责：一个服务只需要干好一件事情，专注才能做好。

什么是微服务？

围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使整个系统变得清晰灵活。

• 原子服务
• 独立进程
• 隔离部署
• 去中心化服务治理

!! 注意：基础设施的建设，复杂度高。

自己的理解：

• 简单说就是微小的服务或应用，比如linux上的各种工具：ls,cat,awk等
• 微服务就是让每个小的服务专注的做好一件事
• 每个服务单独开发和部署，服务之间是完全隔离的

微服务的优缺点

微服务也不是万金油，并不是所有的情况都需要做成微服务，同时微服务也有自己的缺点或者说微服务也会带来一些问题：

• 微服务应用是分布式系统，因此系统必然会比单体应用的时候复杂：开发者不得不使用RPC或者消息传递来实现进程间通信；必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
• 分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对单体式应用来说很容易，因为只有一个数据库。在微服务架构中，需要更新不同服务使用的不同的数据库，从而对开发者提供了更高的要求和挑战。
• 测试一个基于微服务的应用也变的很复杂。
• 服务模块的依赖，应用的升级可能会涉及多个服务模块的修改。

优点：

• 迭代周期短，极大的提升开发效率
• 独立部署，独立开发
• 可伸缩性好，能够针对指定的服务进行伸缩
• 故障隔离，不会相互影响

缺点：

• 复杂度增加，一个请求往往要经过多个服务，请求链路比较长
• 监控和定位问题困难
• 服务管理比较复杂

组件化服务

微服务的核心是组件化服务，通过将之前复杂的巨石机构，拆分成不同的服务，来实现组件化。即将应用拆散为一