微服务系统架构

背景

回忆一下微服务架构是如何进化产生的，最早出现的是单体应用架构，后来为了具备一定的扩展和可靠性，就有了垂直拆分架构，也就是加了个负载均衡，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

什么是微服务架构

微服务架构的核心思想是：分而治之，就是开发多个围绕业务领域的组件来构建应用，让组件可以独立的开发、测试、部署和加速。

其优点在于：

• 支持独立迭代按需扩展，适合业务快速变化和扩展
• 支持分布式或多团队开发，不同的团队负责各自不同的领域，相对独立、专注，也就更高效
• 支持多语言混合开发、多版本组件独立部署、测试和共存

微服务架构的前置条件

从技术角度看：服务注册、统一配置、安全认证、统一日志/告警、分布式事务、持续集成等基础服务要前置于业务模块之前完成，该部分工作如果在业务实现后，重构增加该部分功能会增加不必要的成本。

从团队角度看：架构和团队的影响是双向的，微服务在组织的落地需要实践或者点，需要组织内部成员在：服务划分、持续交付、问题分析等领域形成一些经验后，再分步骤推广。

微服务架构的原则

无状态原则

首先，需要定义一下状态，如果数据需要被多个服务或特定服务的多个阶段共享，可以将其成为状态。

无状态原则并不是说在微服务架构中不允许状态的存在，而是要把有状态的服务改变成无状态的独立业务服务，比如：将状态数据在请求间传递或放到分布式存储中，都可以解决状态服务的问题，这样服务就可以按需动态伸缩。

Restful通信风格

• JSON请求和响应，轻量简单，人机可读
• 实现编程语言无关
• 基于无状态HTTP协议，易测试易扩展

前后端分离

简单的说，就是前后端代码物理分离，而不是将：JS, HTML, CSS, JSP都堆到一起，后期难以维护。

微服务架构与SOA架构的异同

相同点：

• 业务被拆分成多个不同的服务
• 单个服务支持部署多个
• 单一服务支持同时多版本部署

不同点：

• 微服务的指导方针中包括：每个服务使用独立的数据库存储
• SOA服务之间通常通过ESB消息总线进行通信，微服务之间通常直接通信

微服务架构适用的场景

• 研发团队：研发团队分布式、多开发语言场景下相对适合，人员在20人以上的规模
• 有独立的运维部署团队
• 业务复杂：10+以上核心业务模块，且业务持续升级改进
• 项目需要长期迭代维护
• 业务处于高速发展期或成熟期

微服务架构不适用的场景

• 初创公司或10人以下的小团队
• 概念验证性质的项目

微服务与单体应用在生产率上的比较

根据马丁·福勒介绍， 在系统复杂度较小时，单体应用的生产率更高，微服务架构反而降低了生产率。但是，当复杂度到了一定规模，无论采用单体应用还是微服务架构，都会降低系统的生产率。区别是：单体应用生产率开始急剧下降，而微服务架构则能缓解生产率下降的程度。如下图：

结束语

在软件开发的世界，没有银弹，架构的选择是基于研发团队、业务需求和市场机会等因素综合考虑的结果，不要人云亦云，也不要因循守旧，

Enjoy GreatSQL :)