最近感觉传统开发的java项目已经做到了瓶颈处，除了深入了解源码的同时，自己也在慢慢往微服务这边发展，但是第一次接触微服务，并不是多么了解里面的概念，所以写个帖子记录一下微服务的概念？微服务到底是什么？
首先我们来看看马丁·福勒先生对微服务架构提出的一个描述：
微服务是一种架构模式，而这种架构模式要满足最基本的五种要求。
（1）微服务是一系列小的服务的组合。
（2）微服务可以单独的去运行。
（3）微服务要围绕着业务模型来做建造。
（4）任何一个微服务都需要独立部署。
（5）尽量避免统一的、集中式的服务管理机制（去中心化管理）。
我们再来看看软件项目的演变过程。
起初，All in One（单机系统），我们可以这样理解，一个大的完整的工程，被放在eclipse/idea中，一般传统行业都采取这种方式，一个项目的所有功能业务都被打包成一个war包，一个工程解决所有事情，但一旦某个环节出错，全体都可能出问题，受影响。
随后，分布式系统就应运而生了，各个模块/服务，各自分离出来，各自形成一个微小的进程，让各个专业的人来关注各个模块的事情，各自独立部署，此时便解决了一个大的war包解决所有问题，哪一个模块出问题并不会影响其它模块，这里完成了软件架构方面的一个质变。
如今，随着技术的进一步完善，这种分布式系统为了把耦合度降解到最低，把每一个模块/业务划分为一个单独的服务，每一个服务都拥有自己的数据库，提供一个单一的服务，能够单独的启动和销毁，同时通过外部的配置，这些服务既能连同一个库，又能拥有自己的库，这样就确保了这个庞大项目健壮的运行，这种形式，也就是现在的微服务形式，甚至一个大的项目中可能拥有上百个微服务。
看完了演变过程，那么我们再来看看微服务的优点：
#每个服务足够内聚，足够小，每个代码容易聚焦。
#一个小团队就能够开发，开发简洁，效率高。
#微服务是松耦合的，是有功能意义的服务，开发部署都是独立的。
#微服务可以使用不同的语言来开发。
#微服务易于和第三方集成，允许容易且灵活的方式集成自动部署。
#微服务只是业务逻辑代码，不会和html，css或其它界面组件混合（前后端分离特别友好）。
#每个微服务都有自己的存储能力，可以有自己的数据库，也可以用统一的数据库。
说完了优点，那么肯定它也有自己的缺点：
#分布式系统复杂性极高，难以看懂。
#多服务运维难度大，运维成本高（原来只要丢一个war包，现在你可能要部署几十上百个服务，并且要监控每一个服务的状态）。
#系统部署依赖繁琐。
#系统的通信成本高。
#数据一致性要求严格。
当然不可能有完美的架构，就像硬币总有正反面，但总体来说，它的优势确实远远高于它的劣势，所以越来越多的大型项目的技术架构选型也逐渐往微服务靠近。
说完的这些概念，再来说说我们程序员最关心的技术栈的问题了，那么一个微服务架构需要那些维度呢？
服务开发：SpringBoot，Spring，SpringMVC
服务的配置与管理：阿里的Diamond，Netflix公司的Archaius等
服务的注册与发现：Eureka，Consul，Zookeeper等
服务的调用：Rest，RPC，gRPC
服务的熔断器：Hystrix，Envoy等
负载均衡：Ribbon，Nginx等
服务的接口调用：Feign等
消息队列：KafKa，RabbitMQ,ActiveMQ等
服务配置中心管理：SpringCloudConfig，Chef等
服务路由（API网关）：Zuul等
服务监控：Zabbix，Nagios，Metrics，Spectator等
全链路追踪：ZipKin，Brave，Dapper等
服务部署：Docker，OpenStack，Kubernetes等
数据流操作开发包：SpringCloud Stream
事件消息总线：SpringCloud Bus
有了这些技术栈，那么我们就需要选择一款微服务框架了，在这里本人选择的是SpringCloud（个人喜欢Sprng啊！），好了，正经点说下理由：
（1）首先Spring的社会活跃，举个例子，选tomcat作为服务器，网上有各种解决方案，但是你选择阿帕奇的另一款玻璃鱼呢，几乎找不到什么帖子来处理问题。
（2）我们再来看看各大bat公司用的微服务架构，阿里的Dubbo/HSF（好舒服），理解为第二代Dubbo,京东的JSF（京舒服），新浪微博Motan，当当网DubboX。这里，从各种社区了解的信息，本人感觉以后也就只剩下Dubbo和Cloud这两者来龙争虎斗了，鉴于对Spring的倾向，本人义无反顾的开始了Cloud的学习，但是最好有空也同时了解下Dubbo，毕竟马爸爸啊。
这里上一下本人了解到的几种框架的对比。
NetFlix/Spring Cloud：完整的微服务框架；支持Rest（唯一支持），Ribbon支持多种可插拔的序列化选择；不支持RPC；支持多语言
Motan：RPC框架，但整合了Zookeeper和Consul，实现了集群环境的基本注册和发现（和其它公司耦合）；不支持Rest；支持RPC；不支持多语言
gRPC（谷歌RPC）：RPC框架；不支持Rest；支持RPC；支持多语言
Thrift：RPC框架；不支持Rest；支持RPC；支持多语言
Dubbo/DubboX：服务框架；不支持Rest；支持RPC；不支持多语言
其实还有一些，本人综合一下，主要在cloud和dubbo对比，但是dubbo睡觉了5年（it界的应该都知道吧，dubbo社区已经不维护了），所以感觉还是Cloud比较值得信赖。
好了，那么来吧？开始我们的微服务入门吧，遇事不决进官网，首先spring.io走起。我们先看看SpringCloud是什么。
~~~~~~~~~~~~~~~~~~~~~~~~~官网阅读中~~~~~~~~~~~~~~~~~~~~~~~~~~~~
