聊聊微服务架构
微服务架构风格就是一种将单个应用拆分成一组小服务开发的方法，每一个小服务运行在它自己的进程中并且使用轻量的协议通信，通常是一个HTTP资源API。这些服务围绕业务能力构建并且由自动化部署机器部署。这些服务有着最小化的中央管理，这个中央管理可以使用不同语言编写并使用不同的数据存储技术。
———— James Lewis and Martin Fowler
微服务架构简述
作为工程师，在开发一个独立的应用系统时，我们会选择很多方式，比如模块化，组件化然后分工合作最后集成调试验证。那么微服务架构同样给出了另外一种方式，也就是说微服务架构本身对于工程师来说其实是一种新的软件开发方式。这种方式是指工程师开发一组小型服务最后组合成原先我们所需要的应用系统。
但是这些小型服务是有条件的，条件就是
1.这些服务跑在自己的进程中，无关于其他服务，通过全自动化的部署方式独自部署。这是指每个服务依托在一个进程中，不存在多个服务跑在同一个进程中，也无关于其他服务具体内部是什么，采用的是什么语言，当然一个服务不是绝对对应一个进程，事实恰恰相反，一个微型的服务可能由几个进程共同组成。以上条件可以说是微服务独有的特点，这个条件并不是简简单单的将应用独立开来，而是从开发层面根本性的铲除多余的联系，比如开发两个独立的服务，一个服务采用java，一个服务采用go，两个服务各自独立部署，互不影响。
2.采用轻量级的通信机制。虽然在很多微服务架构中很是推崇http，到那时其作为服务之间的的通信调用显然是很重的，这里需要由每个系统的设计者设计系统通信方式和数据编码也就是这些服务之间达成某种协议，采用同一种模式通信，但各自实现的细节可以不同，类似http只是不再局限于http，比如protobuf。
Martin Fowler 的观点
通过阅读Martin Fowler的文章，他提出微服务架构应有的9个特征
1.通过多服务组件化
2.围绕业务功能组织
3.产品而非项目
4.智能端点和“傻瓜”管道
5.去中心化的服务治理
6.去中心化的数据管理
7.基础设施自动化
8.容错设计
9.演进式设计
使用微服务的预备条件
在意识到问服务的优势之后，大部分公司想必会对系统进行微服务化改造，但事情往往不会那么一蹴而就，微服务架构能够解决分布式系统的痛点问题但是却对技术团队提出了高要求。
Martin Fowler在其博客中提到，对业务进行微服务改进时需要开发团队具备高于平均水平的技术条件，以下就是Martin Fowler在其博客中提出的一系列预备条件：
1.Rapid provisioning ：快速地物理资源的提供能力
2.Basic Monitoring : 基础的镜像恢复能力
3.Rapid application deployment: 快速应用发布能力
以上的能力都体现出一种组织的变化：开发与运维间紧密的协作： DevOps（开发运维一体化）的团队文化
除此之外还有很多，比如 根据持续交付以此来跟随和聚焦自身业务；组织集中式的团队；重新组织自己的开发环境以方便开发人员在不同的开发环境下来回切换。
*ps：上周有幸和业界比较出名的几位架构师见面并且聊天，几位架构师聊了下自己公司的现状然后很自然的提到微服务架构，之后提到SpringCloud，其中一位有着10+工作经验的架构师一语道破“玄机”：微服务架构应当是 合适的语言做合适的事，而不是大家一说起微服务就是SpringCloud。本人其实很赞同这句话，微服务在将接口独立出来后，更加解放了系统所采用的语言范畴，发挥各个语言该做的事情，让合适的业务可以自由的选择合适的语言，避免系统被某种语言体系所绑定而带来的多种问题。*