微服务架构和单体应用架构
微服务架构
微服务是一种软件架构风格，由 Martin Fowler 提出来。
软件开发领域没有银弹，一个架构或者框架有好的一面，一定也有不好的一面。
微服务架构定义
开发单个应用的一种开发模式。
单个应用作为小型服务套件的一部分。
每个应用都运行在自己的进程中。
应用于应用之间的通信，是通过轻量级的机制，通常是 HTTP 的资源 API。
服务通常围绕业务能力进行构建。
服务可以独立部署。
服务之间没有中央化的管理模式。
每个服务可以通过不同的编程语言来编写，可以使用不同的数据存储技术。
微服务变得复杂的地方
事务
事务处理会变得非常复杂。
部署
进行细粒度的功能拆分以后，会多出多个项目，每个都项目需要部署。
调用链追踪
为了快速定位可能产生的问题，需要对整个调用链非常清楚。
传统单体架构
单体应用
一个单体应用通常构建为一个独立的单元。
企业应用
企业应用通常是构建在三个主要部分之上。
客户端用户界面
包含 html、js
数据库
包含表、关系数据库、数据库管理系统
服务端应用
处理 http 的请求，执行领域逻辑，获取、更新数据库的数据，选择并且装配 html 视图，并且把视图发送给浏览器。服务端应用是一个单体的可执行的逻辑。对于系统的任何修改，都涉及到构建、部署服务端应用的一个新版本。
两种架构风格对比
这种单体的服务器，是一种这样系统自然而然的构建方式。用于处理一个请求的所有的逻辑都会运行在一个单个的进程当中，这样的话，就可以使用编程语言的基本特性，将应用分解成类、函数、命名空间。可以水平的对单体应用进行可伸缩的处理（扩容、减容），方式就是在一个负载均衡器后面运行多个实例。
单体应用非常成功，但是逐渐地人们开始对它们感受到沮丧，特别是有更多的应用被部署到云端的时候，这种变化都联系到了一起，对于一个应用任何一个非常很小的修改和改变，都需要让整个单体应用进行一次重新构建和部署。随着时间的推移，我们很难保持很好的模块化结构，这个使得保持只对一个模块的变更变得越来越困难了。可伸缩就要求整个应用进行可伸缩，而不是应用的部分进行可伸缩，这种做法就需要更多的资源。
比如：我只想对商品详情页面进行更好的可伸缩，而公告、投诉这些模块不需要，要是单体应用就只有整个应用一起可伸缩了，不能只针对一个具体的模块进行可伸缩。
单体应用的可伸缩
一个单体应用会将它所有的功能都放置在一个进程中，单体应用典型的表现形式。通过复制这个单体应用在多个机器上面，比如要部署 4 个单体应用，就需要复制成 4 份，分别放置在 4 台机器上。通过在多个服务器上去复制一个单体应用的实例来完成可伸缩，而且每一台机器的实例内容都是一样的。
微服务应用的可伸缩
微服务架构会将每一个功能元素放置在单独的服务当中，服务与服务之间是完全独立的。通过跨服务器来分发这些服务，在需要的时候才进行复制。非常的灵活，完全根据需要来复制。而且每一台机器的实例内容可以一样，也可以完全不一样。
可伸缩对比
如下图所示（左边为单体应用，右边为微服务应用）：
这些沮丧导致了微服务架构风格的出现，构建应用做为服务的套件，服务是独立的、可部署的、可伸缩的。每一个服务都提供了一个坚实的模块边界，甚至允许不同的服务可以用不同的编程语言来编写，它们还可以由不同的团队来进行管理。
我们不会去表明微服务架构风格是非常创新卓越的，它可以追溯到 Unix 的设计原则。但是我们认为，并没有太多的人去考虑过这种微服务架构。并且我们也会认为，很多软件开发如果使用了微服务架构，都会从中获益匪浅。
参考资料
Last updated
