什么是微服务
一、微服务、分布式、集群的区别
概念：
- 集群：复制应用
- 相同的模块，在不同的服务器上
- 分布式：分散压力
- 不同模块部署在不同的服务器上。
- 微服务：分散能力
- 将分布式的集群模块里面的功能，提取出来。
比如：外汇交易系统， Trade.war / Batch.war /
- 集群：
- 多台机器，都同时启动着 Trade.war 和 Batch.war
- 分布式：
- 几台启动Trade.war ，几台启动 Batch.war，
- 微服务：
- Trade.war中，小功能拆出来，比如Trade变成 多个模块，对单业务负责，对单功能负责。
二、微服务的特点
- 每个微服务仅对单个业务负责，且为该业务的容量负责；
- 每个微服务可以进行独立部署，即不需要依赖其它微服务及其相关资源，如数据库、内存缓存系统等；
- 服务的可替代性，代表着每个微服务原则上都可以使用不同的语言、框架进行技术实现，且更换实现后的微服务对于整个业务系统不会造成影响；
- 每个微服务拥有单独的数据存储；
- 每个微服务由小团队维护，服务以业务来进行拆分后，每个微服务的维护工作将有人数不多的小团队进行维护；
- 独立的可扩展性，每个微服务都可以独立进行横向或纵向扩展，根据业务实际增长情况来进行快速扩展；
- 轻量级的通信协议，例如REST、STOMP、AMQP等；
- 独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程；
三、微服务的好处
易维护性：
每个微服务的代码均只专注于完成该单个业务范畴的事情，因此微服务项目代码数量将减少至IDE可以快速加载的大小，这样可以提高了代码的可读性，进而可以提高研发人员的生产效率；语言无关性：
研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目（当然，一般根据每个公司的实际技术栈需要来了），这样在面对新技术或新框架的选用时，微服务能够更好地进行快速响应；故障和资源的隔离性：
在系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，将仅仅只会影响单个微服务；优化跨团队沟通：
如果要完全实践微服务架构设计风格，研发团队势必会按照新的原则来进行划分，由之前的按照技能、职能划分的方式变为按照业务（单个微服务）来进行划分，如此这般团队里将有各个方向技能的研发人员，沟通效率上来说要优于之前按照技能进行划分的组织架构；-
原生基于“云”的系统架构设计：
基于微服务架构设计风格，我们能构建出来原生对于“云”具备超高友好度的系统，与常用容器工具如Docker能够很方便地结合，构建持续发布系统与IaaS、PaaS平台对接，使其能够方便的部署于各类“云”上，如公用云、私有云以及混合云。总结：1、复杂度可控。2、独立部署。3、技术选型灵活。4、容错。5、扩展
四、微服务面临的挑战
【问题1:整体监控】
- 不同的技术或语言
- 依靠不同的机器或容器
- 使用其特有的版本控制
挑战：想监控整体的架构，是非常困难的。
【问题2:日志的管理】
- 出现异常，如何快速找到错误日志
挑战：微服务都是将程序分解成独立的组建，作为其副作用，事务控制和日志管理，都需要被分解，如何适当使用工具集中管理
【问题3:基础服务出现问题】
- 比如我们的数据库，XNETD、MQ、Redis，他们出现了异常，会导致其他微服务无法正常使用。
挑战：基础服务如何做到高可用，保证稳定性。
【问题4:寻找问题的根源】
- 我们已经定位到是那台机的问题，出问题的日志，但是实际呢？真正的原因呢？可能会出现的情况是，A服务调用了B服务，B服务有调用了C服务，C服务报错了，我们定位到C服务，发现是B服务的问题，再去定位B服务，发现是A服务的问题，在去寻找A服务，如果我们每个服务的数量，不是1，是2，是5，是10呢？
挑战：定位问题后，如何快速的定位根源，需要加入很多的记录，很多描述，便于后面的是你，关键是找到一个集中的根源监控工具。
【问题5:版本管理，以及更新版本】
- 微服务改造升级过程中，无法保证做到所有服务是完全分开的，那么如何控制版本的启动先后顺序，更新的顺序，以及出现问题后的回滚版本问题。
挑战：更新版本的复杂度，策略，操作规范，出现问题的处理措施，运维成本。
