微服务初体验

微服务是一种风格，原来的是all in one(单体架构),微服务完美的阐述了高内聚，低耦合的意思。

即微服务是一种利用分治法的思想，去把一整套非常复杂的业务逻辑给切分成多个简单的业务问题，并采用模块化方法去实现组合的一种架构方法。

它们是相互独立的，这意味着它们可以采用不同的编程语言和数据存储。微服务中几乎不存在集中管理，它使用轻量级的HTTP、REST或Thrift API来进行内部通信。

微服务官方介绍 ： https://blog.csdn.net/qq_43458555/article/details/108468384

微服务风格（microservice style）

它用于描述一种设计应用程序的特别方式，作为一套独立可部署的服务。

简而言之，微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。

整体应用程序（Monolithic applications）相当成功，但是越来越多的人感觉到有点不妥，特别是在云中部署时。变更发布周期被绑定了——只是变更应用程序的一小部分，却要求整个重新构建和部署。随着时间的推移，很难再保持一个好的模块化结构，使得一个模块的变更很难不影响到其它模块。扩展就需要整个应用程序的扩展，而不能进行部分扩展。

这导致了微服务架构风格（microservice architectural style）的出现：把应用程序构建为一套服务。事实是，服务可以独立部署和扩展，每个服务提供了一个坚实的模块边界，甚至不同的服务可以用不同的编程语言编写。它们可以被不同的团队管理。

组件化（Componentization ）与服务（Services），组件（component）是一个可独立替换和升级的软件单元。

当寻找把一个大的应用程序拆分成小的部分时，通常管理都会集中在技术层面，UI团队、服务端业务逻辑团队和数据库团队。当使用这种标准对团队进行划分时，甚至小小的更变都将导致跨团队项目协作，从而消耗时间和预算审批。一个高效的团队会针对这种情况进行改善，两权相害取其轻。业务逻辑无处不在。实践中，这就是 Conway’s Law 的一个例子。

设计一个系统的任何组织（广义上）都会产生这样一种设计，其结构是组织交流结构的复制。

——Melvyn Conway, 1967

Melvyn Conway 的意思是，像下图所展示的，设计一个系统时，将人员划分为 UI 团队，中间件团队，DBA 团队，那么相应地，软件系统也就会自然地被划分为 UI 界面，中间件系统，数据库。

微服务（microservice ）的划分方法不同，它倾向围绕业务功能的组织来分割服务。这些服务实现商业领域的软件，包括用户界面，持久化存储，任何的外部协作。因此，团队是跨职能的（cross-functional），包含开发过程所要求的所有技能：用户体验（user-experience）、数据库（database）和项目管理（project management）。

Amazon 理念是“你构建，你运维（you build, you run it）”.

Guardian网站就是这方面的一个优秀的例子，它初期被设计和构建成一个整体架构，但它已经向微服务的发展了。整体构架仍然是它网站的核心，但是他们使用微服务来增加那些使用整体架构API的新特性。这种方法增加这些临时的特性非常方便，比如运动新闻的特稿。这样站点的一个部分可以使用快速的开发语言迅速整合起来，当它过时后可以一次性移除。我们发现一家金融机构用相似的方法增加新的市场营销活动，数周或者几个月后把它撤销。

微服务的优缺点？

微服务的优缺点：https://www.zhihu.com/question/65502802

以上就是本次的微服务初体验所有的内容了。