什么是微服务？为何你要用微服务？

​

前言

最近几年微服务很火，你们都在建设微服务，仿佛不谈点微服务相关的技术，都显得不是那么主流了。

近几年见识到身边朋友的不少公司和团队都在尝试进行微服务的改变，但不少团队并无实际微服务踩坑经验，不少团队甚至强行为了微服务而去微服务，最终写成一个大型的分布式单体应用，就是改造后的系统既没有微服务的快速扩容，灵活发布的特性，也让本来的单体应用失去了方便开发，部署容易的特性（项目拆为多份，开发部署复杂度都提升了），不得不说是得不偿失。

做者亲身经历和参与几个大型项目微服务的改造和建设。因此想做为实践者跟你们分享关于微服务的实际经验，帮助你们了解微服务的优缺点，从而能够结合自身业务作出更加合适的选择，做为本篇文章的三个主题，例如：

1. 什么是微服务？为何要用微服务？
2. 微服务解决什么问题，又引入了什么问题？
3. 使用微服务应该要遵循哪些原则？什么样的状况你不该该使用微服务？

（PS：由于市面上太多对若是使用微服务框架工具的教程，因此本篇只是一篇关于微服务的整体概述性文章，不涉及各类微服务框架的安装和使用教程，咱们只谈论微服务自己的设计模式的优缺点和适合应用的场景）

一：什么是微服务？为何要用微服务？

什么是微服务？（熟悉的同窗能够直接跳过）

简单举例：看军事新闻的同窗应该都知道，一艘航空母舰做战能力虽然很强，可是弱点太明显，就是防护能力太差，单艘的航空母舰不多单独行动，一般航空母舰战斗群才是主要军事力量，你能够把单艘航母理解为的单体应用（防护差，机动性很差），把航母战斗群（调度复杂，维护费用高）理解为微服务。

大部分的开发者经历和开发过单体应用，不管是传统的 Servlet + JSP，仍是 SSM，仍是如今的 SpringBoot，它们都是单体应用，那么长期陪伴咱们的单体应用有什么弊端？咱们是面临了什么问题，致使咱们要抛弃单体应用转向微服务架构？我的总结主要问题以下：

• 部署成本高（不管是修改1行代码，仍是10行代码，都要全量替换）
• 改动影响大，风险高（不论代码改动多小，成本都相同）
• 由于成本高，风险高，因此致使部署频率低（没法快速交付客户需求）

固然还有例如没法知足快速扩容，弹性伸缩，没法适应云环境特性等问题，但咱们不一一详谈了，以上的问题，都是微服务架构要解决的问题，至于具体是怎么解决的，咱们先放到后面再聊

 

 

​

二：微服务解决什么问题，又引入了什么问题？

咱们先看看微服务能带给咱们什么？微服务架构的特色：

• 针对特定服务发布，影响小，风险小，成本低
• 频繁发布版本，快速交付需求
• 低成本扩容，弹性伸缩，适应云环境

 

咱们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给咱们带来了什么问题？我的总结以下：

• 分布式系统的复杂性
• 部署，测试和监控的成本问题
• 分布式事务和CAP的相关问题

 

系统应用由原来的单体变成几十到几百个不一样的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤为是服务拆分，须要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，而且积极投入，在多方中间取得平衡。

对于分布式系统，部署，测试和监控都须要大量的中间件来支撑，并且中间件自己也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，仍是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队总体的技术栈水平总体要求更高

​

 

 

三：使用微服务应该遵循哪些原则？

古人云：兵马未动，粮草先行。建设微服务是须要创建长远规划，不是像写CMS那样建好数据库表，而后就开始干活，这样十有八九是会失败的。咱们要进行微服务改造前，架构师要提早作好规划，咱们把这里分为三步，前期阶段，设计阶段，技术阶段

前期阶段，大体要作好以下事情：

• 和多方充分沟通，确保能符合客户和组织的需求，而且获得认同
• 和团队沟通，让队友（开发/测试/运维）理解，而且积极投入
• 和业务部门沟通，指定版本计划和上线时间

 

设计阶段，参考 Sam Newman 的著做《微服务设计》，单微服务必需要知足如下的条件，才符合微服务的基本要求：

• 标准的 REST 风格接口（基于 HTTP 和 JSON 格式）
• 独立部署，避免共享数据库（避免由于数据库而影响整个分布式系统）
• 业务上的高内聚，减小依赖（从设计上要避免服务过大或者过小）

 

庞大的分布式系统，须要强大基础设施来支撑，微服务涉及哪些基础设施？

• CI/CD和自动化（分布式系统几乎不可能经过人工手动发布）
• 虚拟化技术（要保证微服务运行环境隔离，目前行业主流的是使用 Docker 容器）
• 日志聚合，全链路监控（高度可观察和分析诊断问题）

 

说了那么多，那什么样的状况下，你的团队不适合建设微服务？（请勿对号入座）

1. 开发团队不具有自主性，所在组织对开发团队限制很是多（具体请参考 康威定律）
2. 团队不熟悉业务，没法识别出服务的边界，进行合理的拆分（请参考 DDD 领域驱动设计）

 

 

​

 

总结

微服务设计实际上是很早就有的设计思想，由于随着虚拟化技术的崛起，微服务能够低成本的实现，因此也开始流行和兴起。

微服务的内涵很深，其中就包括，自动化，去中心化，独立性等等，其中细节没法用一篇文章概述清楚，咱们在作技术选型或者方案的时候，尽量多去了解技术的自己和起源再结合咱们业务的特色，进行更好的选择。

我的知识有限，不喜勿喷，对于微服务你又有什么不一样的见解呢？欢迎来留言进行讨论和交流