一个系统会划分前端与后端，前端是用户看到的，可操作的可视化界面。后端是用户看不到的，负责处理业务逻辑，数据存储的。
在系统发展的早期，我们一般都是以单体模式出现。
单体模式优点：
- 容易开发：不讲究复用、遇到什么新需求都造个新“轮子”，这样最容易开发；
- 容易回溯：遇到问题的时候很容易定位是哪个新造的“轮子”出了问题；
- 容易部署：系统新功能上线，因为只有一套后端代码，把改过的代码拷贝过来，就可以了；
- 容易克隆：别人想买系统，直接复制、粘贴一下就好了。
随着需求越来越多，功能越来越复杂，单体模式的弊端就会暴露出来了。
单体模式缺点：
- 迭代和维护成本增加：系统规则还小时，一个新功能可能只与三五个已有功能关联，所以改动起来容易。但是随着系统功能越来越多，一个新功能可能跟十几个、甚至更多已有功能关联时，要改其中一个功能，可谓牵一发而动全身，工作量会变得陡然增加；
- 工作交接困难：不同功能由不同程序员写的，又调用了别的程序员写的代码，交接起来可能哪些是自己写的都分不出来，别人的更不知道怎么维护；
- 重构难度巨大：万一哪天性能或复杂度到一定极限，需对代码进行优化重构，旧的代码重度耦合，根本无从下手。
由于单体模式长远来看明显弊大于利，所以程序员就开始思考如何有规划的写代码。
MVCMVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码。
MVC是从代码意义的层面出发，将代码分为了负责调度用的Controller控制器、负责业务逻辑和数据库处理的Model模型、负责最终数据呈现的View视图三部分。
相对于最开始的“一锅粥”的混沌状态，现在代码间有了一些边界，程序员分工、代码定位也更清晰了。
模块化与分布式MVC解决了代码内部管理的不少问题，但是从整个系统的视角来看，依然是一个单体。随着业务规模越来越大，某几个功能的流量可能占用了服务器绝大部分资源，于是就产生了两个问题：
- 功能的稳定性如何保障？
- 单台服务器的处理能力达到瓶颈后如何处理？
聪明的程序员就想到，把关键的业务逻辑和主系统剥离开来，形成独立的模块，这样关键逻辑就能单独运作，不受系统其它逻辑故障的影响。当该模块用户量多的时候，还可以把模块多复制几份同时运行，这样其中一个模块不幸挂了，那么其他模块还能接替他继续运作。
把多个模块放在同一台服务上，并没有解决服务器处理能力极限的问题，于是就找老板要为这台服务器升级配置，结果一出价格，吓得老板直哆嗦。
配置提高一点，价格就高了很多，花同样的钱能买好几台原来配置一样的机器。如果改成买多几台机器，然后想办法让这些机器处理能力能叠在一起，性能还可以远超升级的配置。
于是就有了分布式的诞生，多买几台几台服务器，让他们同时工作。服务器还可以选择部署在全国不同的地方，实现了用户的就近区域访问，让不同地区用户都能享受最佳的访问速度。
微服务分布式的架构看似帮程序员们解决了很多的问题，但是新的问题又随之而来：
- 按什么标准去将代码独立成新模块？按技术的喜好、代码的作用、还是按业务模块区分？
- 未来独立的模块越来越多，那该如何管理？
微服务的到来，就为这些问题打开了新思路
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
微服务中有几个关键启：
- 小：将大系统拆成一组小的服务
- 独立：每个服务互相独立
- 轻：我们可以简单理解为代码之间通过一套标准化、大众化的方式互相沟通
- 业务：服务围绕着业务进行构建（微服务最终选择了以业务结构作为其服务划分）
马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
微服务架构
微服务其实是对模块化和分布式的一种升级。
首先，后端增加了统一的“门面”——网关。
有了网关之后，前端就不需要知道众多的服务他们分布在哪里，只需要请求网关，由网关将需求传递到相应的服务中。网关还能自动帮前端找到最快且稳定的服务节点，让前端体验更胜一筹。
诸多的服务分散在不同的地方，为了将这些服务组织管理起来，知道他们用途、状态信息，避免后续发展成一共有多少个服务都无法统计，就诞生了服务池的“管理机构”。所有服务都必须在管理机构内注册登记、及时上报自身情况。
稍微复杂点的功能，都需要多个服务互相配合才能完成的。
单体模式时代，由于只有一套系统，程序员顺藤摸瓜就能找到bug出在哪。现在存在多个独立的服务，程序员必须每个服务逐一排查故障，这就让找bug根源问题变得非常困难，于是就需要一套故障追踪机制，记录前端请求在后端实现的全链路，以便发现问题出在哪。
微服务实践为了让程序员可以更好将系统架构向微服务迁移，于是就衍生出了微服务的代码框架，其中比较出名的方案有SpringCloud、Dubbo两家，我们来简单看看他们他们的官方示例图。
从SpringCloud的架构中不难看出微服务的相对于原有的分布式架构的新特征：
- 网关：对前后端的沟通进行统一的管理。
- 注册中心：用于对所有服务进行管理，服务必须在注册中心注册登记才能使用
- 配置中心：每个服务的配置不是在各自服务内进行，而是统一放在“配置中心”便于管理
- 分布式追踪器：就是用来配合程序员定位一个功能链条中是哪个环节出了问题
微服务不是某种新技术，更像是技术架构的一种新思想，一种正在不断迭代的、用业务的思想解决技术问题的思路。业务驱动下产生的微服务，无疑让写代码这件事变得更具挑战性，但却让程序更能直接表达其价值，能让企业的业务更好、更快的发展。
业务驱动微服务研发工作流
当我们讨论产品方案时，都不能脱离业务，业务是需求最重要的根源，那到底什么是业务呢？
从词语定义来说，业务是指某个行业或者某个职务所做的事情，就叫做“业务”，其参与者是人，未来也可能是电脑、机器（AI、自动化），其目的满足行业、职务的服务对象的需要。
业务方在工作过程中，为了实现更高的产能、获得更高的回报，就会想办法去优化整个业务流程，这就产生了“需求”。只要业务想发展、在发展，需求就会源源不断的产生。
产品经理接触的需求来源，外部是业务的服务对象：用户；内部则是业务的执行方：老板、运营、商务、财务、法务、供应商等。业务方将需求告知产品经理，产品经理经过调研论证，将需求转换为产品方案，输出可以满足业务需求的产品需求文档、原型。
然后，产品将功能的需求提给研发人员，研发最终将这些功能得以实现，于是系统诞生了。业务方使用系统，不断发展扩大，产生更多的新需求，于是以此往复，形成业务-产品-研发的需求链条闭环。
在这个链条闭环里，业务形态、流程决定了系统最终的形态，而系统形态则推动业务的发展。产品是连接业务与系统的纽带，技术并不是在瞎逛，而是根据产品的需求去研发系统，技术研发出来的系统会最终决定业务未来的走向。
架构转变
服务是技术让代码更适应业务发展的产物，是业务驱动下的产物。
微服务的概念需要程序员更了解业务的板块划分和发展方向，代码要随着业务的不断成熟，按照业务结构进行模块化、服务化，才能方便业务的发展壮大，这就要求程序员要“懂点产品”。
如果程序员一味的按照纯粹的技术方案或者自己拍脑袋定的方向做，那随着业务的迭代发展，很容易出现“这个需求做不了”的问题，因为代码被技术方案禁锢住了，无法适应业务的发展，如果要解决，可能就要重构，时间、人力成本将居高不下。
业务驱动的过程，不是一个“理想”、“理性”的过程，代码讲究的是逻辑，是要“不出bug”、“跑得起来”，但是业务的发展是用户、市场需求不断积累的一个过程，很多需求可能是很主观的，甚至有时候是“灵光一闪而过”的。需求存在不确定性，这就让程序员犯难了，那到底要不要按照这个方向做呢？万一做了用不上要推倒重来怎么办？
这时候就体现出了产品经理与技术人员的协调作用，以及对现有业务架构的划分、对新需求的判断和归类，这将直接影响微服务的架构模块。
也就是说在微服务架构下，业务人员不只要懂业务，还要懂点技术；技术人员不只要懂技术，还要懂点业务。
产品蓝图百度复制过来的蓝图，仅参考
产品蓝图和功能架构图十分相似？其实表现上差不多，但是产品蓝图还包含了对整套系统的发展方向预期，里面的很多模块可能处于“会有的”状态，随着业务的发展不断补全。
有了产品蓝图后，新需求就可以很方便的进行归类，做版本规划时也可以看得出距离预期目标还有哪些没有实现的地方，然后进行补齐。
更重要的是，产品蓝图作为产品设计方向的指导作用，能让技术对产品未来的完整形态一目了然，然后再进行以业务为驱动的代码服务化，这样就能让代码能适应更长远的发展需要，避免盲目设计导致最终影响业务发展、需要推倒重来。
通过产品蓝图、产品规划，产品经理能让技术了解整个业务的未来发展方向，让技术可以更熟悉产品，知道“为什么这么做”、“以后还要做什么”，这样在写代码的时候可以更有方向的做兼容。
总结微服务其实是技术、产品的目标一致化的必然结果，大家都以如何更好的发展业务去进行工作。
产品经理可以不需要深入了解微服务下各种配套的机制、利弊的问题，但需要知道，微服务其实是产品架构在代码层的映射、体现。
一个好的产品架构，将有利于技术框架的成型和发展，反之一个模糊不清、结构混乱的产品架构，将会让技术也无从下手，只能头痛医头的解决眼前的需求，无法从代码层面做长远的兼容、发展考虑。
所以我的观点是，微服务是技术架构适应业务发展的一个过程，如果从技术的工作上看，让代码顺应业务的发展其实是个大难事，关爱程序猿人人有责。而产品经理虽然不需要知道微服务的技术细节和实现方法，但应该更多的强化自己的产品能力，多将业务发展方向的事情与技术同事聊聊、科普一下，有利于技术架构更好的发展。
,
