前言
微服务真的很火，很新，很潮，很多人说到微服务都能侃侃而谈，各种新鲜的名词、概念、框架止不住地蹦出来，但是：什么时候应当实行微服务呢？实行微服务应当要注意些什么呢？，首先我们了解下新生的微服务架构与传统架构有哪些区别。
传统架构
单体架构
Web应用发展早期，大部分Web工程将所有的功能模块打包到一起后放到Web容器中运行，很多企业的Jave应用程序打包成war,ear 它们的主要特点：
- 一个程序包包含了应用所有功能， 通常称之为单体应用。
- 架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风格。
单体架构缺点
- 复杂性逐渐变高 - 由于业务的不断修改深入，系统变得越来越庞大，复杂度越来越高。
- 技术债务逐渐上升 - 参与项目的人员流动，水平不同，人员往往会埋坑，问题没有得到解决，坑越来越多。
- 部署速度逐渐变慢 - 业务模块增多，代码量不断增多，部署启动速度相应的越来越慢。
- 阻碍技术创新 - 技术在发展，历史的架构选型注定了系统形态，新的模块需求依然需要使用老旧的技术。
- 无法按需伸缩（出现IO或CPU瓶颈时需要兼顾或妥协）
微服务架构
微服务是什么
lMartin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
来自：http://www.martinfowler.com/articles/microservices.html
微服务解决了什么
微服务特性
- 每个微服务可独立运行在自己的进程里；
- 一系列独立运行的微服务共同构建起了整个系统；
- 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
- 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
微服务的优点
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
微服务带来的挑战
- 边界清晰 - 软件架构开发中如何合理的划分边界，边界清晰和技术限制之间做出权衡
- 运维要求较高 - 服务之间相互依赖运维需要清晰的知道服务之间的依赖关系
- 分布式的复杂性 - 分布式系统固有的复杂性，网络问题，完整的监控，如何保持一致性，事务保障，高可用性等等
- 接口调整成本高 - 一个服务接口的调整可能涉及到多服务需要同时调整
- 重复劳动 - 一个个微服务既然名曰”服务”，就得五脏俱全，就得螺蛳壳里做道场, 麻雀虽小五脏全该有的基础功能数据库的访问，工具类使用，IO处理，网络，各个服务里面都得处理。
微服务设计原则
- 单一职责原则-[Single Responsible Principle] ，即每个服务只做一件事，并把这件事做好；
- 服务自治原则- 每个微服务需要有自己独立的开发、测试、部署、运维。
- 轻量级通信原则 - 通讯协议需要跨平台，跨语言，不要绑定技术栈。
- 接口明确原则 - 一个微服务接口的修改可能相关联的微服务也需要跟着修改，这时需要提前规划好，避免接口修改
总论
总的来说，从传统架构到SOA再到微服务架构，微服务带来了很多全新的东西，可以解决传统架构的一些问题，但同时对系统的架构技术也提出的更高的要求，实现微服务也需要一定的前提条件，，我们不能一味的认为微服务架构好。微服务这种分开当家当然潇洒，但要知道自己当家也有自己的累。
