微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。
本教程操作环境：windows10系统、Lenovo 小新Air14电脑。
一：什么是微服务？为什么要用微服务？
什么是微服务？（熟悉的同学可以直接跳过）
简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下：
- 部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
- 改动影响大，风险高（不论代码改动多小，成本都相同）
- 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
当然还有例如无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题，但我们不一一详谈了，以上的问题，都是微服务架构要解决的问题，至于具体是怎么解决的，我们先放到后面再聊
三：使用微服务应该遵循哪些原则？
古人云：兵马未动，粮草先行。建设微服务是需要建立长远规划，不是像写CMS那样建好数据库表，然后就开始干活，这样十有八九是会失败的。我们要进行微服务改造前，架构师要提前做好规划，我们把这里分为三步，前期阶段，设计阶段，技术阶段
前期阶段，大致要做好如下事情：
- 和多方充分沟通，确保能符合客户和组织的需求，并且得到认同
- 和团队沟通，让队友（开发/测试/运维）理解，并且积极投入
- 和业务部门沟通，指定版本计划和上线时间
设计阶段，参考 Sam Newman 的著作《微服务设计》，单微服务必须要满足以下的条件，才符合微服务的基本要求：
- 标准的 REST 风格接口（基于 HTTP 和 JSON 格式）
- 独立部署，避免共享数据库（避免因为数据库而影响整个分布式系统）
- 业务上的高内聚，减少依赖（从设计上要避免服务过大或者太小）
庞大的分布式系统，需要强大基础设施来支撑，微服务涉及哪些基础设施？
- CI/CD和自动化（分布式系统几乎不可能通过人工手动发布）
- 虚拟化技术（要保证微服务运行环境隔离，目前行业主流的是使用 Docker 容器）
- 日志聚合，全链路监控（高度可观察和分析诊断问题）
说了那么多，那什么样的情况下，你的团队不适合建设微服务？（请勿对号入座）
- 开发团队不具备自主性，所在组织对开发团队限制非常多（具体请参考 康威定律）
- 团队不熟悉业务，无法识别出服务的边界，进行合理的拆分（请参考 DDD 领域驱动设计）
总结
微服务设计其实是很早就有的设计思想，因为随着虚拟化技术的崛起，微服务可以低成本的实现，所以也开始流行和兴起。
微服务的内涵很深，其中就包括，自动化，去中心化，独立性等等，其中细节无法用一篇文章概述清楚，我们在做技术选型或者方案的时候，尽可能多去了解技术的本身和起源再结合我们业务的特点，进行更好的选择
以上就是什么是微服务的详细内容，更多请关注易知道|edz.cc其它相关文章！
