|
的，事实上，微服务模式就像任何新兴技术一样，在热炒之前已经存在了好几年。它本质上就是面向对象编程在更高级层面的应用，即是应用程序架构。同时，情理之中的是微服务会经常使用HTTP API，尤其是RESTful。而RESTful API正是OOP原则在API设计的应用结果。
稍微扩展一下面向对象编程的过程。使用面向对象编程创建一个程序时，通常会将它分割成几个类，每个类表示一个组件，具有特定的角色，处理相对应的数据子集，这都是耳熟能详的内容。虽然在此讨论面向对象编程并不合适，但是本文内容会涉及到几个关键的方面。如果读者不太熟悉这些内容的话，我建议参考这方面的在线文档。
两个原则——“好裁缝”
我们在设计类的时候，必须遵循2个主要原则：低耦合和高内聚。坦白来讲，我认为这不仅仅是面向对象项目的指导原则，而应该是每个软件项目的明星指导规则(可能存在歧义，不展开)。
-
高内聚：是指组件每部分都是高度一致的愿景，包括它的数据和方法都指向非常具体的某一领域、意义或角色。
-
低耦合：是指每个组件与其他组件之间具备交互次数尽可能少的状况。它隐藏了底层细节，能够独立运行，仅仅暴露必要的接口。
对于微服务来说也是如此，好的面向对象设计会带来最优的微服务设计，个人觉得这点如何强调都不为过。这应该也足以回答为什么以及什么时候考虑采用微服务的问题，接下来继续阐述。
象编程的情况是完全一样。即当需要且能够遵循高内聚、低耦合原则的时候。如果你知道如何以正确的方式将代码拆分为类。那你何必要随意地拆分你的微服务呢?如果一个糟糕的类图由于设计不合理，导致功能代码散落到多个文件内，最终难以维护和管理的话，那我们可以想象一下随意拆分微服务应用，导致一个微应用中运行着完全不同进程时的窘境。
拆分应用的理由
想象两个对象交互有多么容易，只需要调用另一个对象的方法，实现起来也非常容易，而且所有的代码都在一个程序内。而与之相反的微服务架构，应用运行在不同的线程，甚至可能是在不同的机器上，基于网络，采用API进行请求通信。
这显然增加了复杂性。但这么做一定有着充分的理由，既不是为了潮流，也不是为了好玩。我可以保证，如果你随意地使用微服务，所带来的管理一点都不会好玩。
实际上，决定使用API访问方式，与使用微服务的理由是相同的。API能够隐藏接口背后的所有实现细节，这在某些情况下是非常重要的，它可以带来超过预计的好处。包括：
针对非均匀流量的可伸缩性
假设一个超市应用程序，包含一个库存微服务，它只显示库存文章的数量;一个视图微服务，它使用GPU来检测文章中包含的图片。如果某一时间段，应用收到数千个库存应用的API请求，而只是少数视图微服务的API请求，那就只需要复制多个的库存微服务就可以应对API请求处理，而不需要去成倍增加GPU资源。
而换一种情况来考虑，将所有代码实现都集中在一台机或一个应用程序，且仍然希望通过扩展资源来匹配全部的访问请求，那么就必须整体复制部署，导致明显的非必须资源浪费。
容错弹性
假设有一个银行应用程序的转账微服务总是崩溃，原因可能是偶然的错误，或者更糟一些，软件版本未经测试，存在一个新bug。那是否因为这个原因，将整个银行应用程序都关闭呢?有些顾客并不关心这个业务，他们只是想看看自己资金动向或是用卡而已。
单独部署
按照前面所述的场景，如果要增加一个新功能或需要修复某个bug，微服务可以让我们只部署更新所对应的那个微服务即可，构建和部署时间也相应少很多。此外，还可以把微服务部署到不同的机器上或不同的位置。
完全隔离
对于需要在服务之间实现完全隔离的需求。通过微服务这种方式可以采用不同的数据库(SQL和NoSQL)或完全不同的实现技术。具备最大限度的设计自由
（编辑：葫芦岛站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
