产品经理懂点技术（1）：程序员讲的“微服务”到底是什么？
对产品经理来说，了解技术相关基础知识有助于理解需求的实现过程与原理，帮助与研发更好地沟通。而本文主要跟大家分享一下什么是“微服务”，以及它的起源、演化、架构与实践。
 
  这段时间，程序猿哥哥突然主动到产品汪，希望小汪提供一版最新的产品功能蓝图。小汪好奇向他们打听，结果发现是技术组大佬提出了一个新概念“微服务”，涉及整个系统底层的重构，程序猿们内部也比较迷茫该。于是小汪就了个机会，向技术组大佬请教了一下，到底什么是“微服务”。
01 研发模式的起点：单体模式
  小汪问大佬，什么是“微服务”呀？
  大佬回答说，你知道研发都有什么技术架构么？小汪摇了摇头。技术大佬就说：
 
  一个系统划分为前端和后端，这个你懂吧？前端就是用户看得到、摸得着的，例如APP、小程序、网页等等、管理后台等等；后端是用户看不见的，负责进行逻辑处理和储存各类数据的。
  小汪说，这个我知道，我还知道前后端分离呢！
  大佬接着说：在系统发展的早期，后端就只有一套系统，所有功能的代码都写在这套系统中，我们称之为“单体模式”。
  单体模式的优势：
分布式和微服务的关系容易开发：不讲究复用、遇到什么新需求都造个新“轮子”，这样最容易开发了；
容易回溯：遇到问题的时候很容易定位是哪个新造的“轮子”出了问题；
容易部署：也就是大家常说的“发版”，系统新功能上线，因为只有一套后端代码，所以把改过的代码直接发布一次就行了；
容易克隆：别人想买这个系统时，直接Ctrl+C，Ctrl+V一下就好了。
  随着需求越来越多，功能越来越复杂，单体模式的弊端就会暴露出来：
迭代和维护成本增加：系统规模还小时，一个新功能可能只与三五个已有功能关联，所以改动起来很容易。但是随着系统功能越来越多，一个新功能可能跟十几个、甚至几十个已有功能关联时，要改其中一个功能，可谓牵一发而动全身，这下工作量就会变得陡然增加。
工作交接十分困难：不同功能由不同的程序员写的，又调用了别的程序员写的代码，交接起来哪些是自己写的可能都分不出来，别人也不知道该怎么维护。
重构难度十分巨大：万一哪一天性能或者复杂度到了极限，需要对代码进行优化或重构，旧的代码重度耦合，根本下不去手。
  物理学上，两个和两个以上的体系或者两者运动形式之间相互作用而彼此影响以至于联合起来的现象叫做“耦合”。
  这里的“耦合”是指系统模块间相互依赖、互相影响的意思。模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块间联系越多，其耦合性越强，同时表明其独立性越差。
02 技术架构演化
  由于单体模式长远来看明显弊大于利，所以程序员就开始思考如何有规划的写代码。
1. MVC
  MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。
 
  MVC是从代码意义的层面出发，将代码分为了负责调度用的Controller控制器、负责业务逻辑和数据库处理的Model模型、负责最终数据呈现的View视图三部分。
  相对于最开始的“一锅粥”的混沌状态，现在代码间有了一些边界，程序员分工、代码定位
也更清晰了。
2. 模块化与分布式
  MVC解决了代码内部管理的不少问题，但是从整个系统的视角来看，依然是一个单体。随着业务规模越来越大，某几个功能的流量可能占用了服务器绝大部分资源，于是就产生了两个问题：
功能的稳定性如何保障？
单台服务器的处理能力达到瓶颈后如何处理？
  聪明的程序员就想到，把关键的业务逻辑和主系统剥离开来，形成独立的模块，这样关键逻辑就能单独运作，不受系统其它逻辑故障的影响。当该模块用户量多的时候，还可以把模块多复制几份同时运行，这样其中一个模块不幸挂了，那么其他模块还能接替他继续运作。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。