技术分享|“单身”还是“入微”？一起聊聊微服务的二三事

云原生技术分享系列内容第三篇之——微服务架构篇。

感兴趣的朋友也可以去看行云创新关于云原生技术介绍的其它文章：
《关于容器最通俗的解释，人人都能三分钟搞懂》
《技术分享|关于K8S的通俗解释，如何跨越K8S的使用门槛》

这一篇，我们来聊聊关于单体架构与微服务架构“相爱相杀”的故事。

微服务架构的通俗解释

微服务我们需要理解三个概念：

1、什么是"微"？

微，狭义来讲就是体积小。

2、什么是"服务"？

服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

3、微服务架构以外是什么样子的架构——单体架构

传统的单体架构，是以整个系统为单位进行部署。而微服务，则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。

对于单体应用，如果发现某一业务的请求量非常大，那么是无法单独扩展该业务的，只能拷贝整个单体应用，再部署一套环境，来实现集群。

正因为单体应用的缺陷，才有了微服务。

举个例子，如图：

有了上面的几个基础，我们再来看看微服务的定义：

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

简单来说，微服务就是将原来庞大的单体架构的各个业务模块变为独立的可运行的服务，一些微服务会暴露一个供其他微服务或应用客户端消费的 API，模块与模块之间通过API互相调用。各个业务模块都是一个服务，整个项目有众多服务组成，这就是微服务。

微服务的优缺点

优点

1、它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然项目的功能数量不变，但是应用程序已经被分解成可管理的块或者服务。每个服务都有一个明确定义边界的方式，如远程过程调用（RPC）驱动或消息驱动 API。微服务架构模式强制一定程度的模块化，实际上，使用单体代码来实现是极其困难的。因此，使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。

2、这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合服务 API 契约的技术。当然，更多的组织是希望通过技术选型限制来避免完全混乱的状态。然而，这种自由意味着开发人员不再有可能在这种自由的新项目开始时使用过时的技术。当编写一个新服务时，他们可以选择当前的技术。此外，由于服务较小，使用当前技术重写旧服务将变得更加可行。

3、微服务架构模式可以实现每个微服务独立部署。开发人员根本不需要去协调部署本地变更到服务。这些变更一经测试即可立即部署。比如，UI 团队可以执行 A|B 测试，并快速迭代 UI 变更。微服务架构模式使得持续部署成为可能。

4、微服务架构模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约束的实例数目。此外，您可以使用与服务资源要求最匹配的硬件。

缺点
1、由于微服务是一个分布式系统，其使得整体变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们必须要编写代码来处理局部故障。虽然这些并不是很复杂、高深，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。

2、分区数据库架构。在基于微服务的应用程序中，不同服务所用的数据库不同，开发者需要更新某一业务服务时会变得复杂。

3、测试微服务应用程序也将变得复杂。

4、微服务应用程序通常由大量的服务组成，因此部署基于微服务的应用程序也是相当复杂的。

“单身好”还是“入微好”呢？

单体架构和微服务各有各的优缺点，并不是说谁好谁坏，更重要的是根据项目做架构选型。

比如，单体架构模式只适用于简单、轻量级的应用程序，如果使用它来构建复杂应用，最终会陷入痛苦的境地。微服务架构模式虽然真正应用起来复杂，但是长远来看，它是复杂、持续发展应用的一个更好的选择。

在云原生的时代，企业需要快速，持续，可靠，规模化地交付业务软件，为了更好的利用云环境带来的弹性能力，微服务架构逐渐成为了中大型企业应用架构的不二选择。

但是由于微服务架构的复杂性，企业想要管理好基于微服务架构的应用，也需要具备更高的能力。单单只是进行微服务的治理，已经显得有点单薄，无法解决企业的症结。企业的IT管理者开始重视微服务从定义、开发、质量到使用的全方位管理，另外由于微服务架构具备的复用性优势，在企业中建立微服务的运营能力也成为了一种诉求。

如何解决微服务的缺点？

以往对于微服务人们更加强调微服务的治理，行云创新认为一个服务涉及到创建、开发、发布、使用、运营等多个阶段，单单强调在使用阶段的微服务治理是不够全面的，因此我们提出了服务全生命周期管理模型：

服务的创建
服务的定义
服务的开发
服务的质量
服务的上架
服务的使用
服务的监控
服务的治理
服务的运营
服务的运用

CloudOS将通过全面的产品能力，帮助企业对一个服务的全部生命周期进行管理，帮助企业更好的建设微服务为核心的IT架构：

1、问题：微服务架构模块调用复杂，应用发布、测试复杂。

·进行API规范化定义，围绕API文档进行开发、研发变更管理、调试。API文档可追踪、可找回、可切换。

·实现API管理、版本管理、API订阅、API变更、API通知、API对比、API导入导出。

·API Mock功能，有效解决调试依赖问题，提升研发效率。
·支持HTTP、TCP、GRPC、Web socket等协议。

·实现AP用例管理、API自动化测试、测试报告生成、测试通知、报表统计等。

2、问题：微服务应用管理运维困难

·灰度发布：根据设定的流量策略来控制流量访问不同的版本。

·限流、熔断、降级：根据服务的请求数和响应时间设置流量策略，保证服务，不会出错导致系统瘫痪。

·链路追踪：展示流量在服务与服务之间、服务与网关之间转发的全路径

……

行云创新CloudOS更多相关介绍，请咨询下载技术解决方案白皮书。

《CloudOS解决方案技术白皮书》 （www.Cloudtogo.cn 咨询在线客服即可免费获取）