微服务介绍

一、微服务架构介绍

1、微服务简介

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构(摘抄自百度百科)。

2、微服务的优缺点

优点：

1. 分解：解决了复杂问题，它将可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经分解成可管理的块或者服务。每个服务都有一个明确定义边界的方式。为服务架构模式强制一定程度的模块化。实际上，使用单体代码来实现是极其困难的，因此，使用微服务架构模式，个体服务能够被更快的开发，并且容易理解与维护。
2. 独立开发：这种架构可以使得每个服务都可以独立的开发，开发者可以自由选择任何符合服务API契约的技术。当我们编写一个新的服务时，我们就可以用当前新的技术，而不是必须使用原来最老的框架来开发。
3. 独立部署：微服务架构模式使得每个服务能够独立部署。开发人员根本不需要去协调部署本地变更到服务。
4. 独立扩展：微服务架构模式使得每个服务能够独立扩展。我们可以仅部署满足每个服务的容量和可用性约束的实力数目。此外，我们还可以使用与服务资源要求最匹配的硬件。(如有的需要CPU高一点，专门做缓存的需要内存高一点)

缺点：

1. 微服务是一个分布式系统，使得整体变得复杂，开发者需要选择和实现基于消息或者RPC的线程间的通信。
2. 微服务的另一个挑战是分区数据库。更新多个业务事务是想当年普遍的。这些事务在单体应用中的实现是微不足道的，因为单体只存在一个单独的数据库。在基于微服务的应用程序中，你需要更新不同服务所在的数据库。通常不会选择分布式事务，不仅仅因为CAP定理。他们根本不支持如今高度可扩展的NoSQL数据库和消息代理。您最后不得不使用基于最终一致性的方法，这对开发人员来说具有挑战性。
3. 测试微服务应用程序也很复杂。一个类似的测试类对于微服务来说需要启动该服务及其所依赖的所有服务，或者需要为这些服务配置存根。
4. 实现跨越多服务的变更也是很复杂的。比如变更服务A，如果A依赖于B，B又依赖于C，在单体应用程序中，您可以简单修改相应的模块，整合变更并一次性部署他们。在微服务中你需要仔细规划和协调出现变更的每个服务。
5. 部署微服务程序也很复杂。微服务应用程序通常由大量的服务组成。如Hallo拥有160个不同的服务，Netflix拥有的服务超过600个。一个服务做负载均衡后可能又有读个服务器，这就变得相当复杂。
6. 每个服务都有多个运行时实例，还有更多的移动部件需要配置、部署、扩展和监控。此外，你还需要实现服务发现机制，使得服务能够发现需要与之通信的任何其他服务的位置(主机与端口)。

云计算、云服务、云存储	全栈：
IaaS  基础设施即服务
PasS  平台即服务
SaaS  软件即服务
BaaS  区块链即服务