【从零开始学微服务】04.微服务架构的特点

大家好，欢迎来到万猫学社，跟我一起学，你也能成为微服务专家。

微服务架构被技术大牛们总结出了以下九个特点：

• 服务组件化
• 围绕业务功能
• 产品而不是项目
• 强终端弱管道
• 去中心化管理
• 去中心化数据管理
• 基础设施自动化
• 容错性设计
• 演进式设计

下面我们来逐个详细了解一下。

服务组件化

当我们谈到组件的时候，一般是指可以独立替换、可以独立升级的功能单元。在以往的架构中，我们引入组件时，使用动态链接库或jar包，甚至是一组代码。在微服务架构中，是把服务作为了组件，使用轻量级的HTTP进行远程调用。

这样做有什么好处呢？动态链接库或jar包的引入是不安全的，可以使用反射等技术手段对模块进行修改。而在微服务中服务作为组件时，不在同一个线程中，根本不能对其进行任何修改。

围绕业务功能

在以往的单体架构中，所有代码、所有逻辑、所有模块都集中在一个项目里。根据康威定理，技术团队的组织结构应该被分为：前端研发人员、后端研发人员、数据库运维人员，如下图：

微服务是倾向于围绕业务功能进行服务的划分的，所以每个服务的团队是跨职能的，可能包括所有职能的人员，如下图：

这里随便提一嘴康威定理，它是马尔文·康威（Melvin Edward Conway）在1968年4月发表论文而提出的。

其核心论点是：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
设计系统的架构受制于产生这些设计的组织的沟通结构。

通俗的来讲：系统设计本质上反映了企业的组织机构，系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。

产品而不是项目

在一般情况下，项目是以交付为目的，当项目完成以后就交付给甲方或者运维团队，甚至该项目的开发团队就此解散了。

而在微服务架构中，产出的是产品。所谓的产品就是需要不断演进、不断迭代，一个团段负责产品的整个生命周期。

强终端弱管道

在SOA架构中，使用了企业服务总线（ESB）这一强管道，因为企业服务总线承担了传输协议转换、数据格式转换、服务路由、监控告警等多种功能。如下图：

在微服务中，服务之间使用轻量级的HTTP进行远程调用，也就是弱管道。而在服务自身内部需要实现一些传输协议转换、数据格式转换等功能，也就是强终端。如下图：

文章持续更新，微信搜索「万猫学社」第一时间阅读，关注后回复「电子书」，免费获取12本必读技术书籍。

去中心化管理

在团队管理方面，微服务是去中心化的。负责每一个服务的团队一般都是自治的，包括开发、测试、运维和实施等各个方面，而不是传统的集中式的管理。

去中心化数据管理

这个特点和上一个特点很类似，它是在数据管理方面是去中心化的。在以往的单体架构中，使用的是一个中心数据，如下图：

在微服务架构中，每个服务链接的数据库是可以是不同的，甚至数据库的类型可以可以是不同的，如下图：

基础设施自动化

一个单体系统可以十分方便地通过这些环境被构建、测试和推送。

由于服务被拆分的粒度比较细，所以就会产生数量众多的服务，使用自动化的基础设施是非常必要的。也就是我们经常提及的CI/CD（Continuous Integration，持续集成，Continuous Delivery，持续交付）。

目前的DevOps实践涉及软件应用程序在整个开发生命周期内的持续开发、持续测试、持续集成、持续部署和持续监控。

文章持续更新，微信搜索「万猫学社」第一时间阅读，关注后回复「电子书」，免费获取12本必读技术书籍。

容错性设计

在数量众多的服务之间进行远程调用，难免会因为底层硬件或网络的不可靠而造成失败。所以在服务被设计时就能够容忍错误，比如：超时、重试、失效转移、幂等性、熔断、限流等机制。

演进式设计

因为每个服务的独立开发、独立部署的，所以对服务的变更、升级、替换就变得相对容易。

要对一个大型单体应用进行微服务转型，肯定不是把这个大的单体应用直接干掉，建一个新的微服务系统出来，而是要以增量的、非破坏的方式把某项业务一步步抽离形成新的服务。

更深入了解

以上是对微服务的九个特点通俗易懂的介绍，如果你不满足于此，可以阅读Microservices（https://martinfowler.com/articles/microservices.html）进行更深入的了解。

微信公众号：万猫学社

微信扫描二维码

关注后回复「电子书」

获取12本必读技术书籍