蒲元云计算-您是否适合微服务: 实现微服务的4个先决条件和关键任务

转载本文需要指出来源: EAII企业体系结构创新研究所. 如果您想加入微信小组参加微课程，架构设计和讨论直播，请直接回复公众号: “ EAII企业架构创新研究所”. （微信: eaworld）

“ Mesh应用程序和服务体系结构”是Gartner2016十大战略技术趋势之一，其中很多提到了微服务的概念. 微服务的概念（Microservices）并不是一个新概念，许多公司已经在实践中，例如Google，Netflix，Facebook，Twiter，阿里巴巴. 微服务架构模式的目的是将大型，复杂且长期运行的应用程序构建到一组相互协调的服务中. 可以轻松地在本地改进每种服务.

自去年以来，微服务一直受到许多开发人员的欢迎，并且看到许多项目尝试使用微服务架构，结果令人鼓舞. 但是，微服务体系结构具有以下优点: 独立部署，高可伸缩性和可伸缩性，自由选择开发语言，有效使用资源和故障隔离. 同时，它还带来了分布式事务，服务之间的通信，监视和部署等待新问题.

除了上述问题，我相信每个人也会有一些问题: 我们的公司或系统是否适合选择微服务架构？选择微服务架构之前，我需要准备哪些先决条件知识或先决条件？遇到以上哪些问题，我们该如何解决？需要哪些基本框架或组件来支持微服务架构？我接触微服务已经一年多了，去年我们的团队使用微服务架构来构建我们的数字企业云平台. 同时，我们在该领域投入了大量时间进行学习和研究. 我们有一些经验和学习经验. 让我们一起分享和学习. 下面，我将分享以下几点:

（1）为什么选择微服务架构以及何时选择微服务架构；

（2）讨论实现微服务架构的一些先决条件；

（3）介绍实现微服务架构的关键知识和实践.

在谈到微服务架构时，我们经常要做的一件事就是将其与整体架构进行比较. 整体架构具有以下缺点: 代码维护困难，部署肿，灵活性和可伸缩性有限，阻碍团队和技术创新等. 微服务架构具有以下优点: 简化代码维护，独立部署，高可伸缩性和可伸缩性以及自由选择开发语言等优点. 那么单片架构真的那么脆弱吗？答案显然不是那样. 让我们在他的一篇文章中看一下Martin Fowler的图表:

上图来自Martin Fowler的文章，揭示了生产率与复杂性之间的关系. 当复杂度较小时，单片应用程序（Monolith）的生产率较高. 当复杂度达到一定规模时，单片应用程序的生产率开始急剧下降. 目前，拆分微服务具有成本效益. 因此，在业务场景之外，空谈体系结构绝对是无赖. 异常强大的体系结构设计，如果不能在业务场景中实现，那只是空谈. 因此，架构需要为业务服务，并且架构设计对于不同的业务场景将有所不同. 架构设计不需要追求高大，简单而美丽的架构. 如果它可以满足业务开发的需求，那么它就是一个好的架构. 另外，一个好的架构还没有完全设计出来. 随着业务量和请求量的增长，良好的体系结构也在不断发展. 微服务架构之所以得到广泛认可，是由于业务变化的不可预测性. 微服务架构可以不断发展并迅速适应业务变化. 但是，与单片架构和严格定义的开发项目相比，微服务架构要求每个人都要面对由许多小服务组成的复杂生态系统.

鉴于此，如果长期业务计划不需要微服务架构，或者团队没有实现微服务的一些基本条件，则不建议您盲目地进入微服务的新兴架构领域，或者从试验开始，逐步加入团队. 推广微服务架构.

如上所述，实现微服务架构有一些先决条件，那么基准条件是什么？马丁·福勒（Martin Fowler）在他的一篇文章中给出了他的理解，如下:

（1）快速配置: 每个人都应该能够在几个小时内配置并启用全新的服务器设备. 一般来说，采用云计算解决方案可以大大缩短此处理流程，但是我们也可以在不依赖完整的云服务的情况下实现此目标. 容器技术的不断成熟使其可行；

（2）基本的运维与监控: 由于微服务架构要求我们在同一生产过程中统一大量松散耦合的服务并实现它们的协作，所以通常每个人都很难仅依靠测试检测未来可能性的环境发生了意外故障. 这样，运维监控系统就成为快速发现和定位严重问题的唯一选择；

（3）快速应用程序部署: 由于需要管理大量微服务，因此每个人都必须具有将其快速部署到开发，测试，预启动和生产环境的能力. 通常情况下，我们只能使用部署管道（Deployment Pipeline）来确保整个过程在几个小时内完全完成. 在早期，每个人都可以手动进行干预，但是在随后的操作中，所有相关工作必须由自动化机制完成；

（4）持续改进团队的组织: 著名的康韦定律说“设计系统的组织，所得到的设计等同于组织的通信结构”，因为微服务“根据业务来组织服务”功能”和“服务是产品”功能，我们会将大型应用程序拆分为不同的微服务，并且更倾向于让每个团队负责整个产品的整个生命周期，因此每个团队背后的小团队的组织微服务是跨职能的，包括实现业务所需的综合技能，微服务责任制对个人能力有更高的要求，并且具有更强的自我驱动能力和自我学习能力的人将获得更多的增长机会.

3.1运行期间的配置管理

首先，我们认为配置分为两部分: 运行前的静态配置和运行中的动态配置. 可以读取静态配置部分

我同事的文章“ DevOps软件配置协作管理”，主要介绍运行时的动态配置管理.

服务通常具有许多相关的配置，例如用于访问的连接字符串配置，连接池大小和连接超时配置. 这些配置通常在不同的环境（开发/测试/预发布/生产）中有所不同，例如需要配置的生产环境. 连接池可能不适用于开发和测试环境. 此外，在操作过程中可能还需要动态调整一些参数配置. 例如，在操作过程中，电流极限和保险丝阈值会根据流量条件动态调整. 当前的普遍做法是建立一个运行时配置中心，以支持微服务的动态配置. 下图显示了简化的体系结构:

动态配置存储在集中式配置服务器上. 用户通过管理界面配置和调整服务配置. 特定服务通过计划的pull方法或服务器端push方法更新动态配置. 该方法更可靠，但是会存在延迟和无效的网络开销（假设配置不经常更新）. 服务器推送方法可以及时更新配置，但是实现起来更加复杂. 通常，必须在服务和配置服务器之间建立长连接. 配置中心还需要解决配置版本控制和审核问题. 对于服务环境，配置中心还需要考虑分布式和高可用性问题.

针对类似配置中心的更成熟的开源解决方案是百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond.

3.2基本操作，维护和监视

由于微服务体系结构，大型应用程序被拆分为不同的微服务，并且每个服务都在不同的进程上运行. 因此，有必要为服务建立独立的监视，报警，快速分析和定位机制.

监控是整个操作和维护过程中非常重要的一部分. 监视通常分为两类: 系统监视和应用程序监视.

系统监视着重于运行服务的节点的健康状况，例如CPU，内存，磁盘，网络等. 应用程序监视着重于应用程序本身的健康状况及其相关的依赖关系，例如服务是否本身是否可用，以及它所依赖的服务是否可以正常访问.

我们知道，当系统异常时，可以通过监视来发现异常. 此时，我们可以通过适当的警报机制及时有效地通知相关负责人，以便尽早发现，分析和修复问题. 问题. 但是，当我们面对许多微服务时，由于负载平衡，每个服务将部署多个实例. 使用单片架构查看日志显然是不合适的（成本将在几何上增加）. 通过日志聚合，可以将不同节点的日志有效地聚合到一个集中的位置，便于分析和可视化，并可以快速发现和解决问题. 基本过程如下图所示:

在我们的数字企业云平台中，由于它基于容器技术并使用CoreOS系统，因此我们最终采用了Journald + Fluentd + ElasticSearch技术. 有关更多详细信息，请参见另一位同事的微服务. ，监视如何？ “.

3.3快速部署应用程序

由于需要管理大量的微服务，因此每个人都必须能够将它们快速部署到开发，测试，预启动和生产环境中. 通常情况下云计算 微服务，我们只能使用部署管道（Deployment Pipeline）来确保整个过程在几个小时内完全完成. 在早期，您也可以手动进行干预，但是在随后的操作中，所有相关工作必须由自动机制完成.

部署可能已经经历了三个开发阶段: 手动部署，脚本部署和自动部署（应用程序和基础结构）. 在我们的数字企业云平台中，由于使用了容器技术，最终将其打包到一个映像中并部署到相应的容器中. 为了避免环境差异（物理，虚拟机，容器），我们抽象了一个称为SRM（软件发布管理）的微服务，同时又抽象了另一个称为SEM（软件环境管理）的微服务，它具有以下两个功能: 他们完成了应用程序的快速部署. 它与微服务在其他领域的关系图如下:

那么，他的部署过程如何？ SRM收到部署请求后，将加载产品和组件部署拓扑数据；然后它以与组件相关性相反的顺序向“软件环境管理系统SEM”发起部署请求. 对于单组件部署，SRM将用户指定的部署规范传递给SEM系统. 在SEM系统中，组件根据部署规范进行部署. 当前，部署规范以yaml文件格式描述，主要内容包括镜像地址，部署类型和部署参数等数据. 实际上，SRM中的部署规范主要反映了SEM系统内容容器的服务部署能力. 如下图所示:

以上仅是应用程序自动化部署的过程. 如果您仍然想了解详细信息，则可以阅读同事的另一篇文章《 DevOps的应用程序自动化发行和资源管理》.

3.4持续改进团队的组织

由于微服务具有“根据业务能力组织服务”和“服务即产品”的特性，我们会将大型应用程序划分为不同的域系统，并希望让每个团队负责整个生命周期. 产品. 循环，形成分散的团队组织. 著名的康威定律说: “设计系统的组织，而最终的设计等同于组织的通信结构”. 常见的微服务组织如下:

这原本是个好主意. 每个团队都有权选择适当的开发语言和，并通过RestFul API相互通信，维护更加简化，责任明确，但这也带来了一些优势. 问题: 代码风格不统一，全局系统化考虑不周密，日志格式不统一，依赖关系复杂，服务之间的团队协作性差. 为了解决上述问题，我们对上述组织结构进行了更改（我在这里主要针对研发团队），如下图所示:

总体体系结构小组负责评估和约束每个域中系统的技术选择，以及建立通用标准，基础体系结构的支持以及域系统关系的组合. 这不会导致技术选择过度分散. 为以后的管理和自动自助操作带来方便. 没有自动化，也没有微服务. 自动化包括编译，打包，测试和部署. 将单进程的传统应用程序拆分为一系列的多进程服务后，这意味着开发，调试，测试，监视和部署的复杂性将相应增加. 大型的，必须有合适的自动化基础架构来支持微服务架构模型，否则开发，运营和维护成本将大大增加，正是由于DevOps的存在，微服务才可以使用. 设想将1个应用程序进程部署到1个主机，部署复杂度为1 x 1 = 1云计算 微服务，如果应用程序规模需要部署20个主机，则部署复杂度为1 x 20 =20. 将一个应用程序进程划分为50个微服务进程，部署复杂度变为50 x 20 =1000. 没有自动化设施，仅部署就会杀死人员.

从微服务的定义开始，本文借鉴了微服务的优点和问题，然后将它们分为几个模块: 第一部分，为什么选择微服务体系结构，何时开始实施微服务体系结构；第二部分，关于实现的讨论微服务架构的一些先决条件. 在第三部分中，我们介绍了微服务体系结构实现中的一些关键知识，并全面总结了微服务体系结构的各个方面. 微服务是近年来的一个新概念，但实际上并不是什么新鲜事物. 它有助于大型应用程序分解和转移复杂性，从而可以更有效地并行解决，但不会降低任何复杂性，甚至会引入分布式计算中固有的其他复杂性. 为了更好地理解和实践微服务架构，我们需要有一个清晰的认识.

关于作者:

王照

Pu原信息获得了投资. 我通常喜欢旅行，骑自行车，爬山和其他活动.

关于EAII

EAII（EnterpriseArchitectureInnovationInstitute）企业体系结构创新研究所致力于软件体系结构的创新和实践，以加速企业数字化转型.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-190276-1.html