初识微服务

一、传统架构的缺点

传统架构的典型代表就是单体架构，所谓单体架构就是所有应用是一个大家庭，应用的每个业务模块不分家。但是这种不分家、大杂烩方式的架构在应用业务越来越复杂的今天表现出一系列问题。

• 复杂性逐渐变高：大型网站一般有成百上千乃至上万个业务模块，模块边界不清，逻辑混乱，代码量大，难以理顺。 
• 技术债务逐渐上升：技术人员水平不一，加之人员流动频繁，代码质量不易管理，交接工作也困难。
• 部署速度逐渐变慢：项目越来越庞大，启动速度越来越慢，启动时间占比高，效率低下
• 阻碍技术创新：旧项目技术老，市场人才少；牵一发而动全身，技术更新重构难度大，成本高，风险大。
• 无法按需伸缩：由于一体，不能根据某个业务模块的对服务器的某一领域单方面要求高而调整。如某个业务要求IO密集型，换为固态硬盘即可；另一个业务占用内存多，增加服务器内存即可。单体部署拓展性能要相互考虑各个模块，不能 因为一个模块的调整影响另一模块。

面对统架构的缺点，面向服务架构（SOA）便应运而生，而微服务架构是在SOA的基础上强调“业务要组件化和服务化”，可以说是对SOA的继承和发展。

二、微服务是什么

简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理

这是来自一段英文博客的翻译http://www.martinfowler.com/articles/microservices.html

三、微服务的特点

• 1. 每个微服务可独立运行在自己的进程里；
• 2. 一系列独立运行的微服务共同构建起了整个系统；
• 3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
• 4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用

四、微服务的设计原则

• 单一职责原则：每个微服务只需要实现自己的业务逻辑，其它的不必考虑
• 服务自治原则：每个微服务从开发、测试、运维、乃至数据存储都可以是独立的
• 轻量级通信原则：采用基于REST API http方式通信，不受语言、平台限制
• 接口明确原则：服务之间存在调用，设计之初就要明确各个服务的接口，尽量减少因设计不合理而改动

五、微服务的优点

• 易于开发和维护
• 启动较快
• 局部修改容易部署
• 技术栈不受限
• 按需伸缩
• DevOps

六、微服务的挑战

• 运维要求较高：  服务众多，服务间存在相互调用，出现问题不易定位，要求较高的运维水平
• 分布式的复杂性：要考虑服务的一致性、可用性、容错性等问题
• 接口调整成本高：由于服务间存在相互调用， 服务接口调整，被服务接口也得跟着变动
• 重复劳动：各个业务模块独立，都是一个微服务，某段相同的业务代码，不能抽离共用

七、微服务的代表框架

Dubbo：http://dubbo.apache.org/

Dubbo专注于服务治理，是由阿里开源，国内早起使用较为广泛，后贡献给Apache社区，主要阿里中间件技术团队在维护

SpringCloud：http://projects.spring.io/spring-cloud

SpringCloud提供了一整套的微服务解决方案，近几年在国内广泛流行开来，社区活跃度高，版本更新发布快，属于spring家族。

Dropwizard：http://www.dropwizard.io

Dropwizard由Yammer生产维护，目前已经更新到Dropwizard v1.3.8，在国内使用极其少。

参考：http://dockone.io/article/8539