我所理解的微服务

---

对微服务的基本理解

顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。
体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高1米6，体重90斤的MM，我们说她苗条。微服务也一样，根据亚马逊CEO Bezos给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的two pizza team rule。
具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。关于服务更权威的解释是参考[SOA]（面向服务的架构）。
这个理解显然不够深刻，为了进一步理解其为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是IT软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到SOA架构上。但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

依然SOA

微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有JAVA编写的服务，也可以有PYTHON编写的服务，他们是靠restful架构风格统一成一个系统的。最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性