作为技术者，我们不能只从技术的角度来考虑微服务的价值，而是要从商业价值的角度去衡量它，因为世间的决策者们最终都是逐利的，其能否带来更大的商业价值这一点才是决策者们首要考虑的因素。
1. 微服务带来了扩容的弹性
放在第一位的，当然是我认为最重要的一个好处，以前单片系统，在使用量达到系统规格上限时，就需要扩容，而扩容通常都要从购买硬件做起，刀片，存储……更有甚者甚至还要建设新的机房，构建时间动辄以月计算，这在如今是不能够接受的。
互联网时代，老板们最渴望的是，当客户涌来时，系统有足够的容量能够”笑迎八方客“，而客户稀少之后，又能够将资源释放以保持比较低的运行成本（哪怕省两毛钱电费也是好的），因此，速度和容量相比，容量的弹性其实是更重要的考量因素，因为如今系统面对的通常都是上百万的用户的冲击，而你不能让客户天天面对 “500” 的错误。
服务拆分以后，热点服务可以针对性的进行弹性扩容，而相对冷的模块则可以维持比较低的硬件使用水平。“好钢用在刀刃上”，会为企业带来更高的硬件利用率，从而降低扩容的成本。而相对的，服务拆分带来的性能损失则在次要位置，并且通过性能优化，适当的硬件加强，是可以补足的。
春运是典型的系统容量和请求无法匹配的场景
2. 微服务可以一定程度的缩短交付时间，从而在有限的期限内能够尽可能多的交付功能
老板们当然希望多快好省的上线他们的系统带来商业利益，而多快好省这四个因素里面，多和快往往占着很高的比重，因为功能完备，系统可用性就会比较强，因为上线快速，就会更快的抢占市场获取利益，以战养战，推动商务运作进入正向循环模式。
而这，正是微服务的优势，因为微服务都是独立开发，因此在明确各服务之间接口与关系以后，通过并行开发的方式，采用某种程度的人海战术去堆，确实可以缩减特性功能的上线时间。用项目管理上的说法就是，因为你的模块都独立了，因此任务关键路径全被拆掉了，而关键路径缩短就意味着交付时间的提前。在经营者的眼睛里面看，这就意味着可以更快的抢占市场创造价值。而以战养战，迭代获利，无疑是微服务的一个重要魅力。
但是，再强调一点，老板们的成本并没有降低，因为微服务带来的系统复杂性的提高，开发整套系统的成本甚至还增高了，时间缩短和成本降低没有必然联系，这一点必须要有清醒的认识。
3. 微服务带来了功能更新的便捷
如今商业需求千变万化，需求热点的更迭速度都是以天来计算，而之前的系统特性从设计到交付都需要花费半年的时间，甚至更久。这在如今的商业模式下是会错过很多市场窗口期的。系统设计的再精妙，再完备，再无懈可击，不能带来商业价值也不过是垃圾一堆而已。
微服务的局部更新能力解决了这个问题，微服务本质上就是在说解耦，整体
微服务这一点就非常优秀，因为模块小，因此可以“润物细无声“的一点点的上线，而不用一股脑的扔上去，对于老板们来讲，这确实太吸引人了，它可以把功能分解成数个小服务逐个的上线，每次上线速度都会比原来一整块的上线要快。就算是某一次更新出错了，你只要把有问题的模块拿下来就好了，不用那么大张旗鼓的回退。尤其对于互联网企业来讲，是一个致命的吸引力。
4. 微服务的架构在地理容灾方面会有一定的成本降低
做过地理容灾的人都知道，现在说两地三中心，同城备份，跨域备份，很多时候都是以一整套系统为单位进行复制，在不同的地理位置去构建完全一样的系统以备万一，花钱就是两倍，三倍甚至更多，这显然是CXO们不乐意看到的情景。
到了微服务时代，每一个服务组件都是可以替换的，而且每一个组件都要求有自愈的功能，我们就可以在组件的粒度上去进行更精细的控制，而且更能充分的发挥备份系统的能力，最终达到降低成本的目的。
5. 微服务带来了技术异构的可能性
如今的技术没有哪个是完美的，最简单的，C没有自动管理内存的能力，最终写出了很多泄露内存的代码，Java倒是规避了这个，但时不时的GC也很让人困扰。因此很难用同一个技术栈去搞定一个系统所有的问题。从老板们的眼睛来看，当你为了系统1%的问题而大动干戈的时候，就得考虑技术异构了。
先放着一个观点，没事儿别谈技术异构，建议直到“忍无可忍，无需再忍”的时候再搞，例如搞一个Web系统模块，每个都很独立，但是使用框架五花八门，Spring MVC有，Struts2有，纯Servlet也有，请问你的维护组遇到这么五花八门的模块的时候，没有骂娘吗？
异构过多维护成本过大，不做异构会在研发上付出较大代价之间，建议倾向前者。
实施之前的评估，你要考虑的问题有：
- 团队的学习曲线
- 新技术带来的品质问题（更倾向于非功能性问题，例如性能，稳定性，安全性问题等）
- 维护团队维护新组件的成本
（未完待续...下一章开始真正进入讨论实施的话题）
网友评论