微服务的简单介绍

1、微服务的简单介绍

2.1）将一个单一应用程序，按照业务拆分呢为一组小型服务.

2.2）每个服务只做一件事，每个服务运行在自己的进程中

2.3）服务之间通过轻量级的通信机制(httprestapi)

2.4）每个服务都能够独立的部署

2.5）每个服务甚至可以拥有自己的数据库

2.6）微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务

2、微服务的优点

①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码需要了解整个系统)

②：开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了）

③：微服务能够被2-5个人的小团队开发，提高效率

④：服务松耦合，每个服务都能够开发部署。

⑤：前后段分离,作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参

⑥：一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库

3、微服务的缺点

①：增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包

②：服务之间相互调用，增加通信成本

③：数据一致性问题(分布式事物问题)

④：系能监控等..

4、springcloud的技术论坛

    http://springcloud.cn/

    https://springcloud.cc/spring-cloud-dalston.html

5、CAP理论

   Consistency（一致性）：多节点数据数据一致

   Availability（可用性）：用户可以选择向G1或G2发起读操作。不管是哪台服务器，只要收到请求，就必须告诉用户，到底是v0还是v1，否则就不满足可用性

   Partition tolerance（分区容错性）：大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败(由于网路原因)。比如，一台服务器放在北京，另一台服务器放在上海，这就是两个区，它们之间由于网络抖动原因导致不能通信

5.1、Consistency和Availability的矛盾一致性和可用性，为什么不可能同时成立？

答案很简单，因为可能通信失败（即出现分区容错），如果保证G2的一致性，那么G1必须在写操作时，锁定G2的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2不能读写，没有可用性不。如果保证G2的可用性，那么势必不能锁定G2，所以一致性不成立。综上所述，G2无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

5.2、取舍策略
CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但如果如果在分布式的架构下，P是避免不了的。

CP without A：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

 AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

5.3、总结
现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在C和A之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C必须保证，出现网络故障的话，宁可停止服务，可以在A和P之间做取舍。