看了微服务的介绍，感觉概念不难理解，当单体应用过于庞大时（例如微信，集成了一个社区交流的功能），此时将众多功能拆分成多个独立的服务，每个服务都是一个进程，只提供一种功能，可以很方便的部署、更新、容错，这就是微服务。（例如发短信是一个服务，发视频是一个服务，发红包也是一个服务）
笔者没有做过任何服务器开发，因此本文基本靠吹^_^
1、什么是单体应用
单体应用一般来说就是应用的所有功能都在一个进程内实现。
回顾一下MVC模型，在过去SOA的架构中，常用的就是MVC的分层，但是M和C部署在客户端还是服务器端，这对一个应用的规模影响还是非常大的。
笔者认为单体应用分两种类型。一种是B/S架构的，这时候所有的逻辑、数据实际上都在服务器端，因此应用的全部功能是在服务器端实现的.这种情况下，随着应用功能日趋完善，用户量大增，应用的复杂度特别容易膨胀，直接体现就是CPU处理不过来，需要升级硬件。
另一种是C/S架构的，相当一部分的逻辑功能是在客户端实现的，此时应用的功能已经拆分成前端和后端两个进程。一般来说，客户端可以做的比较强大，减少服务器端的负担，然而客户端要求安装，在PC上对环境有种种要求，这也就造成C/S架构的没落（笔者N年前曾经搞过一个客户端，在用户处安装时提示需要某个MFC库，结果被用户冷嘲热讽）。
但是进入移动时代，C/S架构又开始盛行起来，原因是移动网络的流量并不大，减少客户端和服务器端大数据量的交互是很重要的。当然，客户端的功能也会开始膨胀起来。
通过上述描述，一般微服务化都是在服务器端，特别是B/S架构，但是在移动客户端，是否也适合使用微服务？遗憾的是笔者到现在都没有听说过类似的案例。下图是一个单体应用的例子。
2、微服务的要求
B/S架构早就盛行多年，单体应用膨胀也不是近期才出现，但是为什么现在微服务火了？原因是配套技术成熟了。上图的单体应用经过微服务化后变成下图的模型
REST API(Representational State Transfer)：说直接点，就是通信协议。将各种语言（C/JAVA/PYTHON等）转译成通用表述性语言（HTML5，XML等），通过统一通信协议，消除各个服务、前后端之间的语言障碍。试想一下为什么不用RPC通信方式？android的binder还提供了跨进程直接调用接口的方法，实际上也有微服务使用RPC通信，但是随着更多服务通过其他新兴语言实现，它们之间是否还可以使用RPC通信呢？所以使用REST API也是有备无患把^_^
dockers：跨平台的服务容器，其原理类似虚拟机，但是相比于VM，它的优点是启动快、占用资源少，如果服务非常多，完全可以根据应用情况来启动/停止服务，极大提升资源利用率。貌似可以将各种语言编写的服务打包装载到dockers，而且技术门槛很低，运维人员就能操作完成，甚至可以自动化部署。（笔者没用过，都是靠耳闻）
负载均衡：这个应该不是什么新技术，但是对于微服务来说还是很重要的，因为微服务本意就是降低应用的性能瓶颈，服务越多，使用的资源就越多，只有将服务分布到不同服务器上，才能降低成本。（单一服务器升级成本远高于部署多个服务器）
其他：存储技术、数据库技术等等，因为笔者很少使用，也就不好理解。
3、微服务的思考
开头提过，微服务是因为单体应用太大而演化出来的，而微服务的理念和DDD也有相关性（一个领域就是一个服务），因此笔者也在思考在客户端的单体应用是否也可以使用微服务的思想？
现在客户端的功能已经非常复杂，虽然未必有性能问题，但是开发和维护难度也很大。如果使用DDD将客户端按照功能拆分成众多小领域，是否也能提升开发和维护效率？（不要求服务化，只要求领域化）
