浅谈微服务的优点

微服务是个极其复杂的概念，作者就一下表面问题浅谈一二。
篇幅有限，涉猎不深，有兴趣还请自行查阅。

目录

• 微服务的意义
• 架构理念
• 微服务的好处
• 微服务框架

术语解释

RPC：全称 Remote Procedure Call 中文 远程过程调用, 可以理解为调用远程机器上的方法。
单体架构：所有业务代码都在一起。

微服务的意义

我们在开发一个基础的商城程序时， 可能会包含若干模块， 如：用户模块 商品模块 广告模块 订单模块。
在系统建设初期，为了追求系统快速上线，我们可能会把一整套的模块代码， 都放到一个项目代码中。
这样的弊端：
1 . 在后期流量上来后我们发现某个模块功能失效，导致整个项目瘫痪，
举例：
公司进行业务推广，广告模块流量激增，但在此之前，没有做服务拆分，广告模块的高流量导致数据库和带宽无法支撑，最终整个项目进入黑洞状态，用户无法下单，就连商城的界面也打不开。
上面的例子简单说明了传统开发模式的弊端，那么，将微服务理念加入之后呢？
示例：
在莫名的建议下，开发组将商城系统进行了模块服务拆分，这样广告模块就是一个独立的服务，用户参与活动时，直接从客户端调用活动服务，活动服务需要验证其他模块数据的时候，又通过RPC调用进行服务间的数据交互，从而实现压力的分摊，不在让全部服务压力都积压到单台服务器或者数据库上。

架构理念

随着需求的迭代，新功能的诞生，代码库会越来越大，尽管我们竭尽全力，希望将巨大的代码库做到清晰的模块化，但事实上模块与模块之间的界限很难划清，慢慢的，相似的代码随处可见，冗余的代码越来越多，修复bug和新功能越发吃力。
微服务则将这一理念应用在独立的服务上，根据业务的边界确定服务的边界，每个服务专注于服务边界之内的事情，因为可以避免很多由于代码库过大衍生出来的各种问题。
那么一个微服务到底应该多微小？足够小即可，不要过小。那么怎么衡量一个系统是否拆足够小了呢？当你面对这个系统时，不会再有 "过大" 想要拆小它的欲望时，那么它应该就足够小了。使用的服务越小，独立性带来的好处就越多，但管理大量的服务也会更加复杂

微服务的好处

1. 扩展，如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样可以把那些不需要扩展的服务运行在更廉价的服务器上，节省成本。
2. 可组合性，在微服务架构下，更细粒度的服务拆分会将这一优点体现得更淋漓尽致，像拼图一样组合功能。
3. 高度自治，一个微服务就是一个独立的实体，可以独立被部署，也可以作为一个进程存在.
4. 重构性高， 如果面对传统模式的（单体架构）的系统，里面的代码混乱丑陋，没人敢轻易去重构，但是如果你面对的是小规模及其小粒度的服务呢？重构一个服务甚至是重写，都是一件相对容易的事。
   我相信在（单体架构）删除一百行代码，将是一件致命的事情，但是在规划清晰的微服务架构下，删除一个服务也可以游刃有余。

微服务框架

所谓的微服务框架，是一种错误的说法，微服务是一种架构性上的概念，和框架无关。
我们服务间的互相调用，可以用 HTTP 协议 或者是 原生 TCP 协议 来实现，因此实际上，微服务和框架没有一点关系。
如果真要说是微服务框架的话，无非是封装了一些组件，让你更轻松的实现RPC调用。
真正的微服务，最核心的其实是如何做好服务间的最小粒度切分，是架构规划的范畴。

小结

本篇主要将微服务和单体架构之间进行了对比，彰显了微服务的优点，具体使用还是要看具体情况。