详解微服务Micro Service
微服务的概念我们应该大体了解了，那么微服务又是怎么来的？原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗？ 实际上，并非原来“大一统”（Monolith）的服务化实践不能满足要求，也不是不好，只是，它有自己存在的合理场景。 对于 Monolith 服务来说，如果团队不大，软件复杂度不高，那么，使用 Monolith 的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。 但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于 Monolith 的服务化思路就开始“捉襟见肘”。 在开发阶段，如果我们遵循 Monolith 的服务化理念，通常会将所有功能的实现都统一归到一个开发项目下，但随着功能的膨胀，这些功能一定会分发给不同的研发人员进行开发，造成的后果就是，大家在提交代码的时候频繁冲突并需要解决这些冲突，单一的开发项目成为了开发期间所有人的工作瓶颈。 为了减轻这种苦恼，我们自然会将项目按照要开发的功能拆分为不同的项目，从而负责不同功能的研发人员就可以在自己的代码项目上进行开发，从而解决了大家无法在开发阶段并行开发的苦恼。 到了软件交付阶段，如果我们遵循 Monolith 的服务化理念，那么，我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付。 这就涉及服务化早期实践中比较有名的“火车模型”，即交付的服务就像一辆火车，而这个服务相关的所有功能对应的项目成果，就是要装上火车车厢的一件件货物，交付的列车只有等到所有项目都开发测试完成后才可以装车出发，完成整个服务的交付。 很显然，只要有一个车厢没有准备好货物（即功能项目未开发测试完成），火车就不能发车，服务就不能交付，这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付，那么就不需要都等同一辆火车，各自出发就可以了。 顺着这个思路，自然而然地，大家逐渐各自独立，每一个功能或者少数相近的功能作为单一项目开发完成后将作为一个独立的服务单元进行交付，从而在服务交付阶段，大家也能够并行不悖，各自演化而不受影响。 所以，随着服务和系统的复杂度逐渐飙升，为了能够在整个软件的交付链路上高效扩展，将独立的功能和服务单元进行拆分，从而形成一个一个的微服务是自然而然发生的事情。
这就像打不同的战役一样，在双方兵力不多、战场复杂度不高的情况下，Monolith 的统一指挥调度方式是合适的。而一旦要打大的战役（类似于系统复杂度提升），双方一定会投入大量的兵力（软件研发团队的规模增长），如果还是在狭小甚至固定的战场上进行厮杀，显然施展不开！ 所以，小战役有小战役的打法，大战役有大战役的战法，而微服务实际上就是一种帮助扩展组织能力、提升团队效率的应对“大战役”的方法，它帮助我们从软件开发到交付，进而到团队和组织层面多方位进行扩展。 总的来说，一方面微服务可以帮助我们应对飙升的系统复杂度；另一个方面，微服务可以帮助我们进行更大范围的扩展，从开发阶段项目并行开发的扩展，到交付阶段并行交付的扩展，再到相应的组织结构和组织能力的扩展，皆因微服务而受惠。
微服务解决什么问题，又引入了什么问题？
我们先看看微服务能带给我们什么？微服务架构的特点：
- 针对特定服务发布，影响小，风险小，成本低
- 频繁发布版本，快速交付需求
- 低成本扩容，弹性伸缩，适应云环境
我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？个人总结如下：
- 分布式系统的复杂性
- 部署，测试和监控的成本问题
- 分布式事务和CAP的相关问题
系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。
对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高
使用微服务应该遵循哪些原则？
古人云：兵马未动，粮草先行。建设微服务是需要建立长远规划，不是像写CMS那样建好数据库表，然后就开始干活，这样十有八九是会失败的。
我们要进行微服务改造前，架构师要提前做好规划，我们把这里分为三步，前期阶段，设计阶段，技术阶段
前期阶段，大致要做好如下事情：
- 和多方充分沟通，确保能符合客户和组织的需求，并且得到认同
- 和团队沟通，让队友（开发/测试/运维）理解，并且积极投入
- 和业务部门沟通，指定版本计划和上线时间
设计阶段，参考 Sam Newman 的著作《微服务设计》，单微服务必须要满足以下的条件，才符合微服务的基本要求：
- 标准的 REST 风格接口（基于 HTTP 和 JSON 格式）
- 独立部署，避免共享数据库（避免因为数据库而影响整个分布式系统）
- 业务上的高内聚，减少依赖（从设计上要避免服务过大或者太小）
庞大的分布式系统，需要强大基础设施来支撑，微服务涉及哪些基础设施？
- CI/CD和自动化（分布式系统几乎不可能通过人工手动发布）
- 虚拟化技术（要保证微服务运行环境隔离，目前行业主流的是使用 Docker 容器）
- 日志聚合，全链路监控（高度可观察和分析诊断问题）