微服务简介

一：微服务具有以下的特点

1.  按业务划分为一个独立运行的程序，即服务单元
2. 服务之间通过HTTP协议相互通信
           微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制，更多的时候是使用RESTful API
           的，这种接收请求，处理业务逻辑，返回数据的HTTP模式非常高效。并且这种通信机制与平台和语言无关。
           当然服务之间也是可以通过轻量级的消息总线通信，例如RabbitMQ，Kafaka等。
3. 自动化部署
           在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序，单体架构的应用
           程序只需要部署一次，而微服务架构有多个服务就需要部署多少次。所以随着服务数量的增加，如果按照
           单体架构的部署方式，部署的难度就会呈指数增加。那么随着技术的发展，尤其是Docker容器技术的推进，
           以及自动化部署工具（例如开源组件Jenkins）的出现，自动化部署变得越来越简单。自动化部署可以提高
           部署的效率，减少人为的控制，出错的概率降低。随着DevOps这种全新概率的推进，自动化部署必然会成
           为微服务部署的一种方式。
4. 服务集中化管理
           微服务系统是按业务单元来划分服务的，服务数量越多，管理起来越复杂，因此微服务必须使用集中化管理。
           例如SpringCloud采用Eureka来注册服务和发现服务，另外Zookeeper,Consul等都是非常优秀的服务集中化
           管理框架。
5. 分布式架构
           分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外
           提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。分布式系统通过网络协议来通信，所以分
           布式系统在空间上没有任何限制，即分布式服务器可以部署在不同的机房和不同的地区。当然分布式系统比单体
          系统更加复杂，主要体现在相互调用的可靠性，以及分布式事务，全局锁，全局ID等，单体系统则不需要考虑这
          些复杂性。
          另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络
          不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者
          网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务
          不可用。由于服务的相互依赖可能会导致系统的不可用，这就是“雪崩效应”。而为了防止此类事件的发生，分布式
          系统必然采用相应的措施，例如“熔断机制”。 
6. 熔断机制
          为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用SpringCloud构建的微服务系统中，采用了
         熔断器（即Hystrix组件的Circuit Breaker）去做熔断。   

二：微服务的优势

1. 将一个复杂的业务分解成若干个小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。
   服务按照业务拆分，编码也是按照业务拆分，这样代码的可读性和扩展性增加。新人加入团队，不需要了解所
   有的业务代码，只需要了解他所接管的服务的代码，新人的学习成本减少。
2. 由于微服务系统是分布式系统，服务与服务之间没有任何的耦合。随着业务的增加，可以根据业务再拆分服务，
   具有极强的横向扩展能力。随着应用的用户量的增加，并发量增加，可以将微服务集群化部署，从而增加系统
   的负载能力。简而言之，微服务系统的微服务单元具有很强的横向扩展能力。 
3. 服务与服务之间通过HTTP网络通信协议来通信，服务与服务之间完全独立，无耦合，可以自由选择最适合业务
   场景的或者最适合自己的开发语言和技术，提高开发效率，降低开发成本。
4. 微服务的每个服务单元都是独立部署的，当我们修改一个简单应用的时候，不需要测试整个的系统，只需要测试
   被修改的那个服务即可，这个就会大大减少了测试和部署的时间。   

三：微服务的不足

1. 微服务的复杂度
           构建一个微服务系统不是一件容易的事情，微服务系统是分布式系统，构建的复杂度远远超过单体系统，开发
           人员需要付出一定的学习成本去掌握更多的架构知识和框架知识。服务与服务之间通过HTTP协议或者消息传递
           机制通信，开发者需要选出最佳的通信机制，并解决网络服务较差时带来的风险。
           另外服务与服务之间相互依赖，如果修改某一个服务，会对另外一个服务产生影响，如果掌控不好，会产生不必
           要的麻烦。由于服务的依赖性，测试也会变得麻烦，比如修改一个比较基础的服务，可能需要重启所有的服务。
2. 分布式事务
           在微服务架构中，分布式事务一直都是一个难题，即两个操作在不同的服务中，如何保证事务的一致性。
3. 服务的部署
           每个微服务系统可能会涉及比较底层的组件，例如数据库，消息中间件等。微服务系统往往由数量众多的服务构成，
           而每个服务又有大量的实例。微服务系统需要对每个服务进行治理，监控和管理等，而每个服务有大量的配置，还
           需要考虑服务的启动顺序和启动时机等。所以说部署微服务系统，需要开发人员或者运维人员对微服务系统有足够强
           的控制力。当然随着云计算和云服务器的发展，部署微服务也越来越简单。例如：Docker为容器技术，是微服务最佳
           部署的容器。
4. 服务的划分         
           将一个完整的系统拆分成很多个服务，是一件很困难的事，因为这涉及了具体的业务场景，比命名一个类更加
           困难。

四：微服务的功能主要体现在以下几个方面

1. 服务的注册和发现（Eureka）
2. 服务的负载均衡（Ribbon）
3. 服务的容错(Hystrix)
4. 服务网关（Zuul）
5. 服务配置的统一管理（Config）
6. 链路追踪（Sleuth）
7. 实时日志 （网关可以实现监控功能，实时日志输出，对请求进行记录）