微服务架构是最近在互联网企业兴起的一种软件架构风格，两位大牛 James Lewis 和 Martin Fowler 合作了一篇题为《MicroServices》 的文章，对微服务架构的方方面面进行了详细的阐述，在业界影响巨大。那什么是微服务架构？文章是这样描述的：“一系列小型服务的套件协作构成一个完整的应用，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是RESTful风格的API。这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署。这些服务的集中式管理做到了最小化，每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。”
与微服务架构相对应的是单一整体式的应用（Monolithic Application），后者一般是在一个独立的进程中就实现了整个应用，虽然这个应用也是由多个功能模块构成，但是这些功能模块最后是完全绑定在一起，在一个进程空间中运行。相比之下，微服务架构下的应用则将这些功能模块彻底的独立出来，放到单独的进程中去运行，服务之间采用进程间通信的机制实现交互，并且每一个服务都很小，大概100行左右的代码就能够实现。
看，就好像批萨饼不过是铺了一层肉和奶酪的馕一样，微服务架构这么新潮的概念，说穿了也不足为奇嘛。我看到Microservices后第一眼也是这么不屑，所谓架构设计，就是“分而治之”的技术，你这拆分成独立服务进程的思路，跟我拆分成独立功能组件的思路，有什么本质的不同？仔细看了相关人的实践经验后，才发现，正是将进程内组件移到进程外独立执行这一点小小的改变，却对软件开发以及产品运维的方式产生了很大的影响，我总结一下有如下几点：
首先，各个服务可以被独立的开发，独立的部署，独立的升级，独立的运维，从而实现功能模块的彻底解耦合。在Monolithic App中，一个小功能的加入或者一个小bug的修改，都会造成整个应用的重新构建和发布，但是在microservices架构下，一般只需要修改小一部分即可。代码改动所带来的风险，并不是和改动代码的规模线性相关。改动一百行所带来的风险，比改十行代码要大十倍以上。微服务模式下，可以尽可能降低每次修改的规模，从而降低整体风险。
其次，良好的架构设计可以被更好的遵守和维持下去。在Monolithic App中，虽然各个模块可以通过头文件等形式来规定接口，但是在进度紧张的压力下，仍然会有开发者图方便绕过这些接口，通过引入全局变量等不好的形式，破坏系统的架构；在大型开发团队中，会有专门的架构看护工具来检查这些违规代码。但是在Microservices架构下，一个服务成了一个黑盒子，必须通过其官方的接口才能够使用其服务。这从根本上保证了架构质量的延续性。
再次，操作系统提供的进程隔离机制，能够提高整个应用的健壮性；Monolithic App运行时如果发生了不可恢复的错误，整个系统就会崩溃，在一个庞大的系统中寻找bug，是非常困难的；但是在分布式的MicroServices应用中，如果某个服务崩溃了，只需要运维系统监控到并且将它马上恢复（比如重新启动这个服务），那么整个系统不会受到影响。同时在各个小服务系统中寻找bug，会容易得多。
然后，是团队管理上的方便，与微服务的方式相比，单一独立应用的一次大的发布可能包含由数百开发人员完成的数千个变更，管理和协调这样的发布是令人恐惧的，我们需要确保每一样东西各就其位并且能相互协调一致。而微服务架构模式下的开发团队，因为有了更加彻底的隔离以及明确的服务契约约定，发布各个服务所需要的管理协调就工作就更加简单。
最后，MicroServices架构风格下，开发团队不仅仅是开发团队，同时还是运维团队，按照亚马逊的说法：You build ，you run it，这样开发团队必然会关注他们的产品是如何在生产环境运行的，必然会和客户进行更多的接触和互动，会更加关注怎么让其产品为客户产生更多的价值。而传统模式的开发团队只负责开发，运维一般是交给专门的运维团队去负责了。
MicroServices虽然优点很多，但是不足之处也是很明显的，一位实践了微服务的兄弟Wootton列举了一些问题：
＃会带来重复代码；其实这一点我不是很明白，重复代码通过使用共享库（静态或动态）的技术应该是可以被解决的；
＃运行开销增大，进程间的通信比进程内模块间通信要慢几个数量级；
＃服务增多之后带来了服务运维部署的难度的增大，每一个服务可能都需要监控；
＃分布式系统的复杂性会远远大于独立一体式应用，可能会降低系统的可靠性；
最后，回到我们的标题，微服务架构适合嵌入式系统吗？与亚马逊的EC2等IT服务不同，嵌入式系统一般是实时性要求极高，但是运维却不由开发者甚至制造商负责，比如电信设备。基于这个特点，我认为嵌入式软件系统不能照搬微IT企业服务架构的做法，不过微服务架构的思想却是可以被借鉴的，从而实现取长补短：
●在架构设计时，对系统进行彻底的解耦合；功能模块分散到各个单独的操作系统进程中；通过进程隔离，实现对解耦设计的保护。
●各功能模块之间通过预先定义好的服务接口进行交互；在这里，我们不能使用HTTP和RESTful的API，这样效率太低；实时操作系统已经提供了更加高效的IPC机制；
●独立的发布，很多嵌入式系统的软件都是一个独立的bin文件，这是一个Monolithic形式的APP，通过微服务的改造，可以将其从业务逻辑的维度，分成多个独立的服务交付件，由不同团队来开发和交付；
●从特性的维度组建跨功能团队，一个服务往往是一个独立的特性，交给一个独立的团队开发，这个团队中往往包含了开发所需要的全部技能，比如UI，数据库，中间件，业务逻辑等。
MicroServices在互联网行业中已经取得了不少成功的应用，应该说是互联网行业快速交付和运维的压力所导致的一个必然结果，但是在嵌入式系统开发过程中是否可行，还需要同行们的更多的思考和实践，以上算是抛砖引玉吧。
