随着云计算和容器化技术的发展成熟，使得应用程序开始向云服务器部署转移，从单台服务器或者由多态服务器各种部署连接构成的服务集群，向虚拟化后的服务集群的过度，要求我们的应用程序架构必须发生转变来适应这种底层服务器的变化。
前面的文章提到过，由于未来的服务一定是运行在云计算平台上的云服务，不管是部署在共有云上面向大众的，还是部署在私有云上面向专门的特定用户的服务，都要求我们的应用开发架构从原来集中式的巨型单体应用程序转变为功能责任单一，能够自己独立部署和自治管理的组件化功能服务转变，这也是云服务原生应用架构的要求。
我们知道作为一个架构师，其核心的能力应该是对应用系统功能按照某种规则进行划分并引入模组设计。
在过去我们所有的应用开发过程中都在做这某种程度的功能划分和模块化设计，但是这种设计往往都是在同一个应用进程环境下的内部逻辑分组设计。
而到了云服务架构下，需要考虑的是基于网络节点的独立服务分组和连接通信问题。
所以在开始考虑采用微服务设计架构时，首先得了解我们的应用程序的部署运行环境，其最理想的部署环境是云服务平台，一种虚拟化的硬件管理和服务技术。
我们可以通过虚拟化的硬件资源在动态的管理和调整服务器的算力资源，存储资源以及网络带宽资源等。
而微服务框架设计方面，我们需要针对这些部署环境特点来作为入口点进行理解。
在过去我们无论是做面向终端用户的互联网应用开发，还是做企业级内部系统开发，我们长期以来形成了一套完整的架构设计规范。
这套规范是以应用服务器容器为外部边界进行设计和开发，也就是说所有的应用功能设计实现都是在容器空间内部来完成的。
其应用程序的生命周期完全由应用程序容器来管理，我们是在应用程序内部创建标准化的组件来实现功能设计，比如我们设计UI组件，业务逻辑组件，数据存储以及内部信息集成组件等。
因为所有的功能组件都是在同一个应用程序容器内部实现的，所以他们之间的交互访问都是通过组件的相互注入调用来实现的，也就我们熟悉的依赖注入函数方法调用的方式。
而到了云服务环境中，我们的应用不再是部署到独立的应用程序容器里，而是需要部署到无数的服务节点上，每个节点上部署的功能组件可能相同也可能不同，而这些独立的服务组件独立完成某个服务内容的提供，并且采用的是分布式是数据存储。
在传统的系统架构里，我们有部署应用程序的应用服务器，有独立的集中式数据库服务器，如果数据量庞大我们可能考虑使用数据库逻辑上的分库分表，但是所有的数据库访问逻辑都会来自同一个应用程序，该应用程序可能会有多个服务节点，但是每个节点运行的服务都应该是相同的。
也就是完全是一个整体服务的多个副本，如果出现了一个用户被路由到了不同的服务节点上，那么就需要解决会话同步问题，这是通常我们会使用缓存服务器来在多个分布式节点服务器中间做一个会话数据缓冲同步。
但是这样的方案还是无法摆脱各个功能组件之间紧耦合问题，只是从一个整个应用层级上进行了冗余扩容处理。
但是要知道我们一个应用系统中面临的并发访问量处理压力并不均匀，也就是说我们一个系统中各个功能部分因为业务功能不同面对的处理压力不同，产生瓶颈的地方也会不同，我们从系统级别上通过复制扩容，虽然能解决部分问题，但是也同时会造成很多非受压功能部分的重复浪费。
也就是说我们不能很好的精致化的管理我们应用程序的弹性设计。
比如拿一个网上商城应用系统来说，其主要的系统功能可能包括用户登录和身份验证的安全模块，包括商品查询模块，包括订单生成和处理模块，支付处理模块，包括出库和配送信息管理模块，还包括很多特殊功能的设置模块，比如活动推广，特殊形式的竞购功能等等。
这里面容易产生处理瓶颈的订单生成和处理模块，支付处理模块等，因为它们的并发处理效率会直接体现在用户的购物体验上，而用户登录和验证我们用户登录安全检查服务等可能就没有上两个模块处理的压力。
但是由于我们传统的单体应用程序架构设计造成了要想扩大某些模块处理能力，我们只能增加整个服务器的处理能力，同时系统的脆弱性也会变大。
如果我们采用微服务架构来进行设计，我们就可以独立出想用户登录和身份验证服务，订单生成和处理服务，支付处理服务等一个个独立的服务处理节点，它们各自保存自己的关联数据，包括应用服务器和数据存储服务器都是独立的，同时我们可以采用同等服务的矩阵方式来避免某单个节点出现问题，而造成整个服务不能使用的问题。
如此依赖所有的通信就变成了服务器节点之间的通信调用，而非同一个进程中线程的函数调用了。即使某个进程出现问题崩溃，完全可以通过技术手段切换到正常的同样功能的其它服务节点的进程调用。
从而通过独立节点的冗余和相关管理调度手段来解决服务脆弱性问题。
同时因为各个功能组件服务独立性，我们可以针对某一部分或者业务环节的服务压力来增加参与处理的节点数，从而通过这种局部功能的弹性化处理，准确的管理服务能力的弹性管理。
同时因为独立性和冗余部署，我们可以很好的避免因为某个功能节点问题而造成的服务脆弱性，通过对服务处理节点状态的检测，我们可以及时发现节点问题从而提前做处理。
由于服务组件做到功能的幂等性，我们可以对某个功能处理的瓶颈任意的扩容，而不会影响整个服务的运行。
微服务架构由于是基于容器化技术来实现对服务运行节点的管理和调度，由此就为我们提供了一个动态的监控和管理服务运行的途径。
特别是容器化技术将运行应用服务的节点从重量级的操作系统的负担中解救出来，让我们节点服务器的开启和关闭变的异常的容易，不用在耗费大量的时间和资源成本。
这就给了我们微服务架构无与伦比的部署灵活性。
文章来源: https://twgreatdaily.com/zh-hans/S0pMa28BMH2_cNUgv2J7.html