架构思考：为什么通信行业需要微服务，需要云原生

  在当前的软件开发领域如果你不谈微服务，不谈云原生，自己都会觉得自己out了。但是在我们通信行业的软件开发中，特别是在我所处的网管领域中，我们为什么要使用微服务架构，在微服务后，我们为什么又要搞云原生?
  对于这个问题，可能每个人都有自己的理解和认识：有的人的可能会说运营商现在的标书都要求微服务，而有的人会说BATJ都采用的微服务，也有人会说友商也都是采用的微服务，但这些是我们也采用微服务的内在本质的原因吗？而在实现了微服务后，我们又要走向云原生，这个是不是自己在"折磨"自己呢？

为什么我们需要微服务

微服务是什么

  理论源于马丁·福勒关于微服务的定义

- 将单体应用划分为一组小服务，服务之间相互协作，实现业务功能 
 - 每个服务运行在独立的进程中，服务间采用轻量级通信机制协作（HTTP/JSON）
 - 每个服务围绕拆分后的业务能力进行构建，并且能够通过自动化机制独立部署 
 - 很少有集中式的服务管理，每个服务可以使用不同的语言和不同的存储技术
 - 是一种基于有界上下文，松耦合的面向服务的架构

  从这个描述可以看出微服务架构的一种面向服务的架构风格，这个风格的特点就是：小，独，轻，松

我们需要微服务

  为什么我们通信行业需要微服务呢？从不同的角度，会有不同驱动力，但是软件最大的目标是要满足业务需要，这个才是软件存在的价值，而从我们业务自身需要的角度来看，NFV和5G无疑是我们网管系统需要采用微服务架构的最大动力。
  在NFV和5G的时代，为了实现万物互联，网元的规模都会远超2，3，4G的时代，因此我们的网管系统就急需一种解决管理海量网元管理的方式，在AKF扩展立方体(Scalability Cube)理论中，我们只有支持三个维度上的扩展，才能比较完美的解决这个问题。

AKF

  而在软件设计中，为了支持这三个维度上的扩展，我们首先想到的就是采用分布式的方式来进行开发，而采用分布式系统的开发，我们就会面临着许多的技术挑战，这些挑战换一种说法就是：复杂，而如果没有还好的管理复杂性的手段，这样的分布式系统必然会走向失败。而微服务架构风格，恰好能帮助我们管理分布式系统的复杂性,并且提供了一套完成的分布式系统搭建指导说明，因此，从我个人来看这才是我们网管系统采用了微服务架构的最重要的原因。

微服务架构如何帮助我们管理分布式系统带来的复杂性？

  一般来说软件的复杂性来自于两个方面：业务复杂性和技术复杂性，而技术复杂性的大小主要是与：软件规模和结构有关，而我们开发人员认为一个系统复杂，主要是因为其模糊，认知负担很重，而微服务架构在如何管理软件的复杂度提供了很好的理论指导：

• 微服务的“小”

  微服务的"小"是指的微服务的业务职责的单一，通过单一的职责，每个微服务自身的结构得到的简化，降低了其开发的技术复杂度

• 微服务的“独”

  微服务的"独"是指的微服务独立运行在单独进程中，从技术上保证了模块之间的交互，是通过接口完整，提升了依赖的规范性，使微服务系统的结构也得到优化，降低了其开发的技术复杂度

• 微服务的“轻”

  微服务的“轻”是指微服务之间通信采用轻量化的协议，开发人员容易掌握

• 微服务的“松”

  微服务的“松”是指微服务之间的依赖小，依赖小意味做模块的内部实现不会传播给依赖者，避免内部的调整，导致了依赖者的修改。

微服务架构如何指导我们搭建分布式系统？

  在分布式系统中，需要处理很多的技术挑战，如:如何找到目标服务，如何实现分布式事务，如何追踪调用过程等，而在微服务架构中，针对这些问题都提出了自己的解决之道，避免了我们在分布式系统搭建的过程中，掉入各种各样的坑中，这些指导原则以模式的方式被总结出来，如下图所示：

微服务架构模式

  从上图中可以看到，微服务架构的模式涉及到：通信，存储，运维等方面，可以全方位的指导我们的分布式系统的设计

小结

  通过上面的分析，我们可以得出这样的结论，之所以网管系统需要采用微服务架构，是由于通信业务的不断发展，网管管理的网元规模爆发式的增长，我们为了应对这一切，需要有一个高度可以扩展的分布式架构，而微服务架构恰好能指导我们如何开发这样的系统，所以网管系统采用了微服务架构既是偶然，也是必然的选择

为什么我们需要云原生

云原生是什么

  Pivotal 公司是云原生概念的早期推广者，同时也是 Spring 框架和 Spring Cloud 的主要贡献者，它对云原生的定义是：

“Cloud-native is an approach to building and running applications that exploits the advantages of the cloud computing delivery model.”——云原生是利用云交付效率的优势来构建和运行应用的方式。

  同时，他还补充道：

“Organizations require a platform for building and operating cloud-native applications and services that automates and integrates the concepts of DevOps, continuous delivery, microservices, and containers.”——组织需要一个平台来构建和运行云原生应用，这个平台要包含 DevOps，持续交付，微服务和容器。

  简单总结一下，也就会说云原生的目的是为了充分利用云的能力使应用交付更快。为了达到这个目的，在进行设计时将充分考虑云为我们提供的便利条件,将用到 DevOps、持续交付、微服务和容器等理念和技术，如下图所示：

云原生

我们需要云原生

  软件行业应该是制造名称，制造概念数一数二的行业，我们作为开发人员和设计人员如果是抱着跟风的态度，就会导致项目出现极大的风险，所以一个新概念，新技术的出现，我们主要注重其到来的价值（注：技术主要带来的价值就是降低复杂度），根据我们实际的情况，反复掂量后，在来看是否要采用

微服务架构面临的困难

  在软件行业大家都认同是不存在可以解决任何问题的“银弹”，当然，微服务架构的系统也面临着一些不容易解决的问题。

  在具体的微服务开发时，我们一般提倡采用六边形架构和整洁架构来进行设计，如下图：

六边形架构

整洁架构

  而在这两种架构中，都强调了业务和基础设施的分层处理，这样的分层是为了让业务开发人员集中精力在核心业务的开发之上，而将基础设施，如：存储，寻址，事务，监控等功能由专门的技术团队来承担，通过这样的隔离实现技术复杂性和业务复杂性之间的隔离，降低微服务开发的复杂度。
  但是在当前的微服务实现中，如：springcloud，主要是将各种基础设施的能力，以SDK库的能力提供给开发人员，开发人员需要了解各种库的使用方式后，才能使用这些基础设施，对开发人员来说是一个很大的认知负担，而且基础设施的实现技术也在不断的变化，这样就会导致虽然业务没有变化，但是基础设施的变化也会导致业务开发人员去改微服务，这些带来的工作量也会阻碍基础设施技术的更新

云原生给我们带来的价值

  云原生可以说是微服务架构的演进的一个必然方向，云原生强调了业务与基础设施之间更彻底的分离，基础设施的能力不在以SDK的方式提供，而是以使用者不感知（如：service mesh）或者统一服务接口（如：微软开源dapr）的实现，这样业务人员认知负担大大减轻，础设施技术也能更快的更新，是微服务架构发展的必然趋势

service mesh

dapr

总结

   在新一代的网管系统中，采用微服务架构是解决NFV和5G时代网元管理规模急速增长的挑战，所作出的一个恰当的选择，但是当前的微服务架构在开发和运维中还存在做不少的困难，因此，进一步向云原生架构的发展，也是一个必然的方向

注：配图来自于互联网