微服务四大问题
1、客户端如何访问那么多的服务？
从表面上看微服务价格模式类似于SOA。微服务是由一组服务注册。然后，换另一种方式去思考微服务架构模式，它是没有商业化的SOA，没有记错web服务规范（WS-）和企业服务总线（ESB）。基于微服务的应用支持更简单、请谅解的协议，例如REST，而不是WS-。他们也尽量避免使用ESB，而是实现微服务本身具有类似ESB的功能。微服务架构也拒绝了SOA的其他部分，例如，数据访问规范模式概念。
微服务的优点
- 解决了复制问题，它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经被分解成客观了的块或者服务。每个服务都有一个明确定义边界的方式，如远程调用驱动或消息驱动API。微服务架构模式强制一定程度的模块化，实际上，使用单体代码来实现是极其困难的。因此使用微服务架构模式，个体服务能被更快地开发，并更容易理解与维护。
- 这种架构使得每个服务都可以由一个团队独立专注开发。开发者可以自由选择任何符合API契约的技术。当然，更多的组织是希望通过技术选型限制来避免完全混乱的状态。然后，这种自由意味着开发人员不再由可能在这种自由的新项目开始时使用过时的技术。当编写一个新服务时，他们可以选择当前的技术。此外，由于服务较小，使用当前技术重新旧服务变得更加可行。
- 微服务架构模式可以实现每个微服务独立不是。开发人员根本不需要去协调部署本地变更到服务。这些变更一经测试即可立即部署。比如UI团队可以执行A|B测试，并快速迭代UI变更。微服务架构模式使得持续部署称为可能。
最后微服务模式使得每个服务能够独立扩展。您可以仅部署满足每个服务的容量和可用性约束的实例数目。此外，您可以使用与服务资源要求最匹配的硬件。
微服务的缺点
与其他技术一样，微服务架构模式也存在缺点。其中一个缺点就是名称本身。微服务这个属于的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的服务，虽然这对于小型服务可能比较好，但是小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。
另一个缺点是由于微服务是一个分布式系统，其使得整体变得复杂开发者需要选择和实现基于小型或者RPC的进程间通信机制。此外，由于目前球球可能很慢或者不可用，他们必须要编写代码来处理局部故障。虽然这些并不是很复杂、高深，但模块间通过语言级防范/过程调用相互通信，这比单体应用要复杂的多。
微服务的另一个挑战是分期数据库架构。更新多个业务实体的业务事务是相当普遍的。这些事务在单体应用中的实现显得微不足道，因为单体只存在一个单独的数据库。在已经微服务的应用程序中，您需要不同服务所用的数据库。通常不会选择分布式事务，不仅仅是因为CAP定理。他们根本不支持如今高度可扩展的NoSql数据库和小型代理，您最后不得不使用基于最终一致性的方法，这对于开发人员来说更具挑战。
测试微服务应用程序也很复杂。例如，使用显得框架如springboot 只需要编写一个测试类来启动一个单体web应用程序并测试其REST API。相比之下，一个类似的测试类对于微服务来说需要启动该服务及其所依赖的所有服务，或者至少为这些服务配置存根。再次声明，虽然这不是已经高深的事情，但不要低估了这样做的复杂性。
另一个主要挑战是实现了跨越多服务变更。例如，我们加速您正在实现一个变更服务A，服务B和服务C的需求，其中A依赖与B，且B依赖于C。在单体应用程序中，您可以简单的修改相应的模块，正好变更并一次性部署他们。想法，在为防止中您需要仔细规划和协调出现的变更至每个服务。
部署基于微服务的应用程序也是相当复杂的。一个单体应用可以很容易的 部署到基于床头负载均衡器的一组相同服务器上。每个应用程序实例都配置有基础设施服务的位置，比如数据库和消息代理。相比之下，微服务应用程序通常由大量的服务注册。
每个服务都有多个运行实例。还有更多的移动部件需要配置、部署、扩展和监控。此外，您还需要实现服务发现机制，使得服务能够发现需要与之通信的任何其他服务的位置。比较传统麻烦的基于票据和收到的操作方式无法扩展到如此复杂的程度。因此，要成功部署微服务应用程序，需要开发人员高度控制部署方式和高度自动化。
一种自动化方式使用线程的平台即服务（PaaS）
总结
构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的应用程序如果您使用它来构建复杂应用，您最早会陷入痛苦的境地。微服务架构模式是复杂、持续发展应用的一个更好选择。尽管它存在着缺点和实现挑战。
若有收获，就点个赞吧
0 人点赞
