这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天，主要讲了微服务架构原理及特征、微服务的核心服务治理功能、字节跳动的服务治理实践等内容。
一、微服务架构详解
1、单体架构 VS 微服务架构
1.1 软件架构定义
软件架构是构建应用系统所需要的一组结构，包括软件元素、元素之间的关系以及两者的属性。其中如何分解软件元素以及这些元素之间的关系，变得非常重要。一个好的软件架构具备两个特点:
- 合理调配生产关系与生产力，让具备不同专业知识与技术栈的的人士都参与到软件系统开发中来， 高效地协同工作;
- 能让各个软件元素有清晰的定义与职责，并有一套良好、高效的交互机制.
1.2 单体应用架构
应用开发采用单体架构，所有的代码在一个代码仓库中管理，最后打包成一个部署包，运行在一个进程上。典型的有三层应用架构与六边形应用架构两种。
1.3 微服务架构
微服务架构其实可以理解为”模块化设计"的扩展延伸，只是这些"功能模块"以单独的部署包的方式运行在各自的进程中。这样每个服务之间都是相互独立的，并且有自己的私有数据库，两者之间仅能通过API的方式进行通信。
2、微服务架构定义与组成
微服务架构中需要考虑决策模型由多个模式组成。从层次上大致可分为应用相关、应用基础相关、基础设施相关三大层。
- 应用相关模式: 服务拆分、数据库的架构、维护数据一致性问题、测试相关;
- 应用基础设施相关模式: 边界问题、安全性、事务性消息、通信风格、可靠性、可监测性;
- 基础设施相关模式: 应用/服务的部署、服务发现等.
2.1 服务拆解
将原来的单体应用系统分解为一系列的服务其实是有难度的，可以遵循以下两种分解策略:
- 根据业务能力分解
- 根据子域分解
2.2 通信方式
使用微服务架构的应用程序是分布式系统，进程间通信是重要组成部分，有以下几种通信模式:
- 通信风格: 使用哪一种的进程间通信机制;
- 服务发现: 客户端如何获得具体实例的真实IP地址;
- 可靠性: 在服务不可用的情况下，如何确保服务之间的可靠通信;
- 事务性消息: 如何将消息发送、事件发布、更新业务数据的数据库事务集成;
- 外部API: 应用客户端如何与服务通信.
2.3 数据一致性模式
在微服务架构下每个服务都有自己独立的数据库，原先在单应用架构下的2PC的事务机制在微服务架构中就不再适用，需要类似于分布式事务的中间件来保证数据的一致性。
3、总结
本篇主要是对微服务架构的一个系统性的介绍，对比了单体应用架构与微服务架构的优缺点，并在微服务架构设计中的需要重点考虑的方面如服务拆分、通信模式、可观测性、安全、部署相关等等相关模式，最后简述了服务拆分的策略与指导原则、远程过程调用与消息交互两种主要的进程间模式的工作原理。
