对微服务的基本理解
顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高1米6，体重90斤的MM，我们说她苗条。微服务也一样，根据亚马逊CEO Bezos给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的two pizza team rule。
具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。
这个理解显然不够深刻，为了进一步理解为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是IT软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到SOA架构上。
但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
依然SOA
微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。
最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于SOA的总线，不过非常轻薄，现在看到的就两种方式：MQ和HTTP，而HTTP都不能完全等同于总线，而仅仅是个信息通道。
所以，基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级。比如：你去年还在使用.NET技术，今年就可以平滑的过度到Go了，而且系统已有服务不用改动。所以微服务架构，既保护用户已有投资，又很容易向新技术演进。
微服务水下的冰山
人月不是银弹，微服务更不是银弹，好像软件微服务化了，软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力，以及背后需要付出的代价。
单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。
同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址，类似于到餐厅吃饭，新菜要写到“菜单”中，以供用户选择。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。
综上所述，微服务关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。
这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
这些系统性的功能也需要有一些服务来提供，这些服务不会直接呈现给最终用户，也就是微服务系统冰山下面的部分，我们可以简称它为微服务系统的“底座”。所有的微服务都像一个APP，插在这个底座的上面，享受这个底座提供的系统能力比如：元数据存放、灰度发布、蓝绿部署等等。
微服务系统底座
一个完整的微服务系统，它的底座最少要包含以下功能：
日志和审计，主要是日志的汇总，分类和查询
监控和告警，主要是监控每个服务的状态，必要时产生告警
消息总线，轻量级的MQ或HTTP
注册发现
负载均衡
部署和升级
事件调度机制
资源管理，如：底层的虚拟机，物理机和网络管理
以下功能不是最小集的一部分，但也属于底座功能：
认证和鉴权
微服务统一代码框架，支持多种编程语言
统一服务构建和打包
统一服务测试
微服务CI/CD流水线
服务依赖关系管理
统一问题跟踪调试框架，俗称调用链
灰度发布
蓝绿部署
令人困惑的几个问题
微服务的底座是不是必须的？
是的，基本上是必须的。你可以不用代码实现一个资源管理服务，可以手工用Excel管理你的所有机器资源，但是不代表微服务系统没有这个功能，只不过这个功能是人工实现的。
再举个例子，日志系统如果只是简单的打印文件，那么多个微服务的日志就需要手工收集，人工分类和筛选。所以，微服务的底座最小集一定会存在，问题是看怎样实现它。
这里仅仅是总结了对微服务系统的基本理解，而实现这个架构有很多技术，这里不进行详细展开。实践方面，推荐王磊的《微服务架构与实践》，他描述了使用Ruby相关的技术实现了一整套微服务系统，特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构，是很好的参考和指导材料。
是不是所有软件都能做微服务？
这个命题有些微妙，也很难说清楚，回答这个命题本身就是一种挑战，可能最终也没有正确答案。不过，我还是把我自己的理解写在这里，让大家去拍砖。在我这里，答案是否定的。我只需举出一个反例，比如：存储系统，其架构是传统的分层架构，每一层都使用下面一层的服务，并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构，但没办法做成微服务。
区别在哪里呢？核心的区别在于独立性上，微服务大多是可以独立的运行和使用的，而存储这种非常底层和基础的系统，每层部件都不能单独被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系统，这些功能都无法离开另外一些功能而独立运行，要对外提供可用的存储功能，一大堆功能必须一起上。这种系统做到极致，最多也就能够使其部件可以独立的部署和升级，俗称打热补丁。
这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密，做成微服务后系统集成成本会大大增加，不仅如此，这样的架构做成微服务并不能提高交付效率，因为各个部分根本就无法独立的运行和测试。
什么样的软件做成微服务？
能不能做成微服务，取决于四个要素：
小：微服务体积小，2 pizza团队。
独：能够独立的部署和运行。
轻：使用轻量级的通信机制和架构。
松：为服务之间是松耦合的。
针对于小、轻、松都是可以通过某些技术手段达到目的，而独立的部署和运行，则是和业务本身有关系，如果你这个系统提供的业务是贴近最终用户的，并且这些功能之间的耦合性很小，则微服务就可以按照业务功能本身的独立性来划分，则这类系统做成微服务是非常合适的。
如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就更加无法做到真正的微服务了。
原文：