云原生之微服务

软件架构演进

单体架构

单体架构是最简单的架构，常见于常见于传统的web开发，将前端代码和所有业务代码放在一个系统里，统一打包并运行，比如传统的J2EE应用，将代码打包成war, 部署在Jboos或tomcat容器中运行。

单体应用存在的问题主要有以下几个：

1. 限制技术栈，比如开发语言只能是统一的。
2. 水平扩展不容易，所有的业务逻辑统一部署，各个业务逻辑所需要的系统资源不一致情况下，扩容只能按照最耗系统资源的业务逻辑去扩容，比较浪费系统资源。
3. 超级大应用，维护成本高，运维负责，定位问题难度大，变更不容易，编辑时间久，部署起来更费劲。

基于SOA的软件架构

SOA的架构也就是面向服务的架构，是单体架构经过水平拆分和垂直拆分的结果，按功能进行抽取代码，独立成各个服务，个服务独立部署，各个服务之间采用统一的协议进行通信。

各服务之间需要调用，引入ESB来管理项目, 可以通过webservice或rpc来实现。

SOA架构存在的问题主要有以下几个：

1. 服务之间调用需要比较正的企业服务总线ESB。
2. SOA更倾向于基于虚拟机或服务器来部署，每个应用都部署在不同的机器上。

基于微服务的系统架构

微服务也是一种服务化，是基于SOA进一步演进而来的更轻量级的服务化。它主要特点包括：

松耦合： 每个微服务内部都可以使用DDD(领域驱动模型)来设计，服务间尽量减少同步调用，多使用消息的方式让服务之间通过领域时间来通信。

轻量级协议：微服务之间更倾向于使用Restful风格的API, 并且各个服务可以用不同语言实现，对于性能要求极高的场景，可以使用protobuff协议。

高度自治和持续集成： 微服务可以很好的和容器化结合，微服务通过docker容器独立部署，互相独立，可以更好地进行扩容或缩容，提升了伸缩性。 并且微服务可以和devops结合，CICD和运维监控都很方便。

微服务的设计原则

前后端分离: 这样前后端分工明确，更专注与各自的分工，最终提供的服务体验更佳。

无状态服务: 将业务服务变成无状态的计算服务，专注于业务逻辑，将有状态的信息存放在DB或缓存中。

REST通信风格: 1. http天然的无状态协议，结合Json，可读性较好，如果需要安全加密，有现成的https协议可用。 2. 语言无关，大部分语言都有成熟的Restful api框架可用。3. 一些特殊场景，采用rpc框架，如grpc, thrift等。

微服务的特征

1. 服务组件化：对服务进行组件化拆分，每个服务都独立开发、部署，可以有效避免一部分功能的修改导致整个系统重新部署或受影响。
2. 对研发的整个生命周期负责： 微服务团队中，每个人对所开发功能的整个生命周期负责，而不是以完成代码开发为目标。
3. 按业务组织团队： 每一个服务的开发者，既要负责数据的存储，又要负责接口的定义等各种夸专业的领域职能。 按业务拆分好团队，可以减少内耗，服务边界清晰。
4. 去中心化治理： 整个微服务架构，通过采用轻量级的接口协议，各个业务服务本身可以结合自己业务特点选择技术栈和框架。
5. 去中心化数据管理： 每个服务可以自行管理自己的数据库，对外提供读写接口。
6. 基础设施自动化： 持续交付平台支撑devops过程。
7. 容错设计：在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录的组件。比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

微服务带来的问题

微服务和单体架构的对比

可以看到，微服务虽然带来了好处，同时也带了了一些复杂性，包括：

• 服务之间的调用复杂，由于分布式部署，常常成网状调用结构。
• 多个独立数据库，事务的实现更具有挑战性。
• 独立的服务数较多，需要有自动化的持续集成系统来支持