微服务基础知识:
1、什么是微服务
微服务是系统架构上的一种设计风格，它的主旨是将单个独立的系统拆分成多个小型服务，
这些小型服务都是在各自独立的进程中运行，服务之间通过http的restful API 进行互相通讯协作，
每个小型服务都是围绕着系统中的每一项或耦合度比较高的业务功能进行构建，
并且每个微服务都维护者自身的数据存储、业务开发、自动化测试案例以及独立部署机制，
由于有轻量级的通讯基础，所以这些微服务可以用不同的语言来写。
2、单个系统的弊端:
由于单个系统部署在一个进程内，往往我们修改了一个很小的功能，但是部署上线后也有出现影响其他功能的风险，
并且，单体应用中这些功能模块的使用场景，并发量，消化的资源类型都各不相同，对于资源的利用又互相影响，这样使得我们对于各个业务模块的系统容量很难给出较为准确的评估，所以， 单体系统的初期可能非常方便地进行开发和试用，但是随着系统的发展，维护成本会越来越大，且难以控制，而拆分出多个小型服务可以帮助我们更加准确的为每个服务评估性能容量，
通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准确的系统性能容量判断。
3、微服务的弊端及挑战
(1)运维的新挑战:
在微服务的架构中，运维人员需要维护的进程数量会大大的增加，有条不紊的将这些进程编排起来和组织起来不是一件容易的事情，传统的运维人员往往很难适应这样的变化，因此， 需要运维人员有更多的技能来应付这样的挑战，运维过程中需要更多的自动化， 需要运维人员具备一定的开发能力来编排运维过程并让它们自动运行起来。
(2)接口的一致性:
虽然拆分了服务，但是业务逻辑上的依赖并没有消失，只是从单体应用中的代码转变成服务之间的通讯依赖，而当我们对原有的接口进行了一些修改，那么作为交互方，也需要进行修改，因此对于接口的一致性， 需要更完善的接口和版本管理，或者严格的遵循开闭原则。
(3)分布式的复杂性:
由于各个微服务都是独立运行在自己的进程中，它们只能进行通讯的方式来交互，所以分布式环境的问题都是微服务架构设计中一个必须要考虑的问题，比如网络延迟、分布式事务、异步消息。
4、微服务架构的九大特性:
(1)服务组件化
在微服务架构中，需要对服务进行组件化分解，服务类似于一个程序化的组件。
(2)按业务组织团队(根据实际情况为准)
对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗，另一方面，团队边界可以变的更加情绪。
(3)做产品的态度(大型系统)
在实施微服务团队中，每个小团队都应该以作产品的方式，对产品的整个生命周期负责。
(4)智能端点与哑管道
在微服务架构中，通常会以下这两种服务调用方式:
a.使用HTTP的RESTful APL或者轻量级的消息发送协议，实现信息传递与服务调用的触发。
b.通过在轻量级消息总线上传递信息，类似于RabbitMQ 等一些提供可靠异步交换的中间件。
(5)去中心化处理:
通常在技术平台上都会制定统一的标准，但是每一种技术平台都有各自的短板，这就导致在碰到短板时，不得不花大力气去 解决，并且可能因为其底层原因解决的不是很好，最终成为系统的瓶颈。
(6)去中心化管理数据:
让每一个服务来管理其自有的数据库，这就是去中心化管理数据。
(7)基础设施自动化:
a.自动化测试: 每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。
b.自动化部署:解放繁琐枯燥的重复操作以及对多个环境的配置管理。
(8)容错设计:
场景:当部分微服务出现故障的时候，其他服务如何应对。
(9)演讲式设计:
以演讲的方式进行系统的搭建。
因为初期的核心业务在后期通常也不会发生巨大的变化，随着系统的发展或者业务的需求，架构师会将一些经常变动或是有一定时间效应的内容进行微服务处理，并逐渐将原来在单系统中多变的模块进行拆分， 而稳定不太变化的模块就形成一个核心微服务存储在整个架构之中。
