微服务是什么

软件系统架构演进历史

单一架构

单一架构是什么？

要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一个容器中运行，那时候的一个B/S应用架构往往是这样的：

 但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：

 后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：

上面3中架构都还是单体应用，只是在部署方面进行了优化

优点：

• 易开发
• 易调试
• 易部署

缺点：

• 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）
• 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。

面向服务的架构（Service Oriented Architecture）

面向服务的架构是什么？

是一种分布式服务架构的常见使用方式，他将但应用程序的不同功能单元（简称服务）进行拆分，并通过这些服务之间定义明确的接口和协议联系起来，进而实现跨服务单元/系统交互能力。

优点：

• 把项目拆分成若干个子项目，不同的团队负责不同的子项目
• 增加功能时只需要在增加一个子项目，调用其它系统的接口就可以
• 可以灵活的进行分布式部署

缺点：

• 系统之间交互需要使用远程通信，接口开发增加工作量

微服务的产生背景

随着大型互联网公司和组织机构对大规模弹性部署和敏捷开发的需求，面向微服务的架构（SOA）逐渐难以应付。同时，伴随这虚拟化技术容器技术的不断发展，持续交付方法论的深入人心，微服务应运而生

微服务

微服务是什么

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块（即服务）为基础，服务之间互相协调配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通讯机制互相沟通。每个服务都围绕具体业务进行架构，并且能够被独立部署。

总结

• 是一套架构方法和体系
• 由很多体量小实现特定功能或业务的服务构成
• 服务低耦合，独立开发部署
• 服务可以使用多种不同语言开发

微服务对比SOA的优势

• 复用率更高
• 响应快
• 弹性扩展
• 支持异构

微服务怎么实现

微服务要解决的问题

• 服务划分
• 服务注册与调用
• 延迟队列
• 服务熔断处理
• 缓存设计
• 分布式事务实现

服务的划分原则

服务的划分是微服务设计的第一步，也是其成败的关键。

• 业务边界清晰

        各服务有清晰的责任及边界，一个服务对应一块业务，服务间多为单向依赖

• 最小的变更

        新增或变更业务上有明确的服务应对，某一业务需求的变更受影响的服务尽可能的少

• 最大化的复用

        服务设定要考虑复用的场景，应该尽可能最大化的实现服务复用

优点：

• 易开发 局部易维护 易部署

        每个服务只关注一个业务功能，代码少业务清晰，开发 维护 部署单个服务简单

• 启动快

        单个服务代码少，使用启动快

• 技术栈不受限制

        每个服务独立可结合团队特点使用不同的语言开发

缺点：

• 业务架构复杂
• 拆分粒度难以把握
• 部署维护困难