从 .Net Framework 到 Windows 和 Linux 容器的 .Net Core 微服务

下载 3

快召唤伙伴们来围观吧
微博 QQ QQ空间 贴吧
文档嵌入链接
<iframe src="https://www.slidestalk.com/u5174/Hongxi_Ma_NET_NET_CoreV10c?embed" frame border="0" width="640" height="360" scrolling="no" allowfullscreen="true">复制
微信扫一扫分享
已成功复制到剪贴板

ccone

发布于

5年前

1834

人观看

#信息技术 flink 大数据阿里巴巴 blink 计算引擎

旧有的 .Net Framework 应用程序仍在企业环境中发挥着重要作用，其中大部分是基于 .Net framework 的单体应用。调查显示，不少公司对 .Net Core 微服务和容器技术有兴趣。然而，让 .Net framework 和 .Net Core 共同存在并相互协作，还需要一些时日。大多数公司必须面对的挑战之一在于，如何构建一个能够供两代使用的统一支持基础架构和平台。在本次演讲中，Hongxi 将展示一个实际案例并介绍包括以下内容的解决方案：1.)使用 Kubernetes 实施和管理的 Windows Server 2016 容器环境和 .Net Framework 服务；2.) 在 Linux 容器中运行的 .Net Core 服务；3.) Kubernetes 支持的 Windows 容器部署中的一些技术挑战。

展开查看详情

2 .行云创新CTO—马洪喜  过去十年一直聚焦于云计算产品研发和项目交付  为最早一批金融、电信行业云计算提供咨询服务  热衷于参加社区活动，连续三年荣获微软MVP 称号  曾供职于 Oracle 、Citrix 、Rancher Labs  现任行云创新 CTO，负责公司开发云产品研发和交付 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 1

4 . X项目曾经面临的挑战 X项目是基于.NET构建的一套复杂的远程实验交付系统。自2011年以来，从最早的远程实验接入，到后来的的复杂实验业务场景交付，其重要性和担当的业务价值越来越大，但其技术架构发展较为缓慢，无法高质量满足多变的业务需求，在运行和维护中由于陈旧架构导致的问题较为突出，也不符合互联网化大背景下的技术架构发展方向。 1 X项目业务发展 2 挑战一：业务需求越来越难以满足。X项目交付量从最初几千班业界技术架构变迁天，发展到几万班天，要处理多种业务。业务需求越来越复杂、差异化明显 X项目运行维护挑战且具有多变性。相对地，X项目架构在过去四年内并未做任何升级改造，客户需求多以“打补丁”的方式满足，难以继续满足未来业务发展需求。 X项目架构发展情况 3 1 2012年3月， X项目二期：引入拓扑图式实验交互模式，增强整体可用挑战二：部分技术已经逐渐落后于行业发展。从行业趋势来性。讲，企业业务正面向互联网化转型，在 “高频率版本发布”、 “更加注重用户体验”等目标驱动下，企业架构更多的开始学习BAT，采用开放平台和技术，如 Linux, Apache, MySQL,Docker等；同时，在开发运维模式上，企业正在由传统的开发和运维分离，向开发运维一体化即DevOps转变。 2 挑战三：运维压力越来越大。当前架构涉及到的组件全部是自行部 2011 2012 2013 2014 2015 2016 署和维护，平台、数据库、监控、应用配置、大数据等，对运维团队提出了较高的要求。具体表现为：底层组件无法跟随上层业务压力变化而变化，出 2012年8月，X项目三期：现问题后定位过程时间长且难度高。 2011年5月，原型验证阶 X项目架构在过去四年主要引入执行引擎，逻辑分段：引入虚拟应用交付技是修修补补，没有实质性离，与设备管理平台对接术。等。 Copyright © 2016 Cloud To Go 变化。 Confidential – do not redistribute without written permission from Cloud To Go 3 3

5 . 代码可维护性项目问题具体分析较差执行力不足新版本上线问 2016年8月，行云顾问组对X项目进行了评估，与题较多，开发全球访包括管理组、需求分析、PM、架构师、开发、测沟通理返工问接口不问速度解变形够丰富试、运维等多位同事进行了访谈，特别就不同角题突出架构未慢，体验不佳无规范色对项目的痛点进行了识别，其中技术架构与流演进，不能满标准程相关问题较为突出，组织和管理方面问题也占用户需足未来采用临求响应需求有一定比例。慢时技术手段多个版虚拟机由架构陈旧引发的问题本同时无法迁维护，开发测 IT技术架构问题移、资源利用试压力巨不充分大需求不清晰，应用扩升级导分析不展性不致线上虚拟机足强服务中等资源断混乱构建测测试不试环境充分、测试上线调进度缓试时间慢长流程、管理、组织问题 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 4

8 . 微服务是X项目重要的技术架构变革传统的单体应用架构与DevOps方法格格不入，特别是X项目经过数年发展，其单体架构已经成为项目发展的关键阻碍。无法有效演进，阻碍对需求模块间依赖性强，相互影响的快速匹配测试成本高，测试不充分，架构修修补补，越发复杂质量无法保证上线时间长，成本高，问题核心技术组件成为发展瓶颈较多单体架构 DevOps 持续交付模块间松耦合，相互独立持续演进，快速达成需求测试范围明确，促成自动化架构灵活扩展，清晰明了测试提高效率只上线变更的服务，通过自按功能点打散，解除瓶颈动化手段形成持续部署能力微服务架构 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 7

9 ..NET Core是X项目重要的技术实现变革使用.NET CORE的开发者比例使用.NET CORE的业务场景使用.NET CORE的开发工具已经使用计划使用暂无计划企业应用互联网后端其它 VisualStudio VS Code 其它暂无计划其它 8% 6% 企业应用其它 27% VS Code 已经使用 37% 26% 44% 计划使用 VisualStudi o 48% 68% 互联网后端 36% 数据来自张善友老师《2018 .NET开发者调查报告》 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 8

10 .变革中需要重点考虑的几个主要问题微服务改造 .NET Core 支撑平台切入点迁移难度如何搭建从核心业务还是周边业现有.NET都能迁移怎么样利用好容器相关务开始到.NET Core吗技术支撑变革 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 9

11 . X项目微服务改造的切入点对于X项目，微服务改造并非‘推倒重来’，而是在过去几年运营的积累上循序渐进完成。‘实验预订’被选为微服务改造的切入点。前端为什么选择‘实验预订’业务？  核心的主线业务流程，覆盖30%以上业务；  完成‘实验预定’的微服务，其余部分迎刃而解；  可以与现有系统较好地过渡，用户无感知；设备查询设备面板实验信息设备预定认证通知  优先解决已成为瓶颈的技术组件，利于后期发展。服务图服务服务服务服务服务基础数据实验模板业务数据域配置数组网虚拟应用账号虚拟机服务服务服务据服务服务服务服务服务微服务拆分的原则是什么？  功能完整性、职责单一性；基础数据实验模板业务数据域配置虚拟应用账号虚拟机  促进可重用性； DB DB DB DB DB DB DB  逐步优化，迭代演进；  接口协议先行，保证兼容性。设备管理活动目录 X项目‘实验预定’业务微服务架构服务服务 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 10

12 ..NET Framework to .NET Core  已有.NET代码和.NET Core的兼容性如何  哪些类型服务需要继续在.NET Framework上运行  数据库选型的考虑，依然SQL Server还是要切换到MySQL  面对新的语言、新的架构，开发人员知识转换难度  设立团队的一些考虑，对需求的准确理解是“重中之重” Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 11

14 . 微服务支撑平台的必要性向微服务架构的转变，仅仅在代码设计上做出改变是不够的，必须结合支撑微服务的平台能力才能让微服务落地、发挥出它的功效。传统微服务对支撑平台的依赖程度运行环境虚拟机容器技术构建方式手动编译持续集成流程生产上线人工部署自动发版诉求工具微服务规模（即业务规模）业务响应被动模式自动伸缩 5 10 20 研发成果互不透明共享复用仅有一两个微服务时，似乎手工操作标准也可以解决，随着微服务规模扩大，发版频率几何增多，变更和运维压力代码管理资源隔离上收统管大大增加。支撑平台 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 13

20 .Federation (联邦) 项目为多集群而生，但还远未可用 “Keep it simple, don't bake too much into 14年开发至今依然Alpha Federation Api server…Migrating Azure to google is not a question for Federation” 技术主张和实际需求偏差巨大 ——Kelsey Hightower, Google 社区活跃度越来越低对AWS and GKE/GCE严重依赖 V1已经废弃，V2才刚刚开始 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 19

23 .X项目采用的DevOps和微服务支撑平台总体架构 1 2 3 4 5 为创新加速的开发服务应用架构设计器前端设计器 Web IDE 自动化测试代码管理云应用商店 6 以业务为中心的PaaS平台基于Docker 采用K8S 多集群和多云 Windows, Linux 服务治理和全面支持容器技术管理容器应用交付容器统一管理安全保护 DevOps方法论私有云 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 22

26 .X项目验证的收益分工清晰、高度可重用多种开发语言采用简单标准协同高效，模块化及开放技术的协议进行团队新成员快速交付业务符合发展趋势服务间调用快速开始一键灰度发布功能持续集成让测根据压力不同随需而用的让新版本上线试和发版快速交付到有针对性的伸基础服务的复杂度高度自动化任意云端缩微服务大大降低 Copyright © 2016 Cloud To Go Confidential – do not redistribute without written permission from Cloud To Go 25

4点赞

0收藏

3下载