【好书推荐】微服务与单一服务架构的拼杀，如何选？

wh7211

1. 如何理解微服务，简要说明您所理解的微服务是什么？

微服务是一种架构风格，一个大型的复杂软件由一个或多个微服务组成。系统中每个微服务都可以被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成任务。在所有情况下，每个任务代表这一个小的业务能力。

微服务的核心思想是一个完整的应用由多个小的、相互独立的微服务组成，这些微服务运行在自己的进程中，开发和发布都没有依赖。不同微服务通过一些轻量级交互机制来通信，服务可独立拓展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立团队维护。微服务的目的是为了根据业务有效拆分应用，实现敏捷开发和部署。



2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？

传统单体架构和微服务架构的优劣对比如下：

微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，一般以集群方式提供服务。

（1）微服务架构的优势

• 模块可独立提供服务，每个服务都比较简单，只关注于一个业务功能，边界清晰，易于维护
• 通过最佳及最合适的不同的编程语言与工具进行开发，易于引入新技术，能够做到有的放矢地解决针对性问题
• 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度
• 微服务商店模式，快速的组合和重构
• 模块间松耦合，不同SLA保障计划，可以提供更高的灵活性
• 微服务架构是持续交付（CD）的巨大推动力，允许在频繁发布不同服务的同时保持系统其它部分的可用性和稳定性
• 更好的可扩展性和鲁棒性
  

（2）传统单体架构的劣势

• 加载、编译耗时长
• 代码管理复杂
• 横向扩展难
• 各模块之间的耦合程度高
• 随着新需求的增加，更新和修复大型整体式应用越来越困难
• 应用功能的快速上线能力差
• 快速变化的需求受到整体式应用的限制
• 随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式
  

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？

会遇到微服务给DevOps带来的下列挑战：

（1）服务使用不同的编程语言开发，因此要为每种语言准备编译环境，为每个服务的部署准备不同的库和框架，让服务的开发和部署变得非常复杂；
（2）大量的微服务模块，复杂的版本管理和BUG跟踪，间接导致项目管理成本增加；
（3）分布式架构特性，服务分布在多个主机集群上，很难持续跟踪指定服务究竟运行在哪台主机上，后续的系统维护不方便；
（4）一个服务一个虚拟机，随着微服务架构不停的横向扩展，主机数量将快速增长，最小规模的主机配置可能也会超过了很多微服务对资源的要求，从而造成了超量配置并浪费开销；
（5）运维开销及成本增加，一个整体式系统如果由20个微服务组成，可能需要40-60个进程；
（6）必须具有DevOps开发运维一体化技能，具有较强DevOps技能的人员比较稀缺；
（7）隐式接口与接口匹配问题，把系统分为多个协作组件后会产生新的接口，在实际环境中，微服务架构会有更高的发布风险；
（8）代码重复，某些底层功能需要被多个服务所用，为了避免将”同步耦合引入到系统中“，有时候需要向不同服务添加同样的代码，这就会导致代码重复；
（9）分布式系统的复杂性，作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题；
（10）异步机制，微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化；
（11）可测性的挑战，在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试；
（12）部署复杂，一个微服务应用一般由大批服务构成，这就形成大量需要配置、部署、扩展和监控的部分。

容器可以轻松实现微服务化后的DevOps，具备“独立性，细粒度，快速创建和销毁以及完善的管理工具”等特点的Docker可以为微服务提供一个完美的运行环境，当然，支持微服务的容器管理平台也需要解决诸如“基础架构服务管理，生命周期管理和团队协作，配置管理和部署支持”等问题。