|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
当前,以微服务、DevOps、容器、多云业务管理为代表的云原生技术已经广泛成熟应用,成为加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。而信创支持、国产化支持,是中国企业数字化转型不得不满足的基本要求。更有专家指出,在关乎企业生存的必选项“数字化转型”以及国家信创战略的共同冲击下,企业需要改变现有业务和IT的架构,更快速地应对挑战、响应变化,增强自身的竞争力。
" {7 w3 a0 G/ e/ `( q# [! U, {5 |9 A7 N3 I3 t! ^
行云创新专业打造信创微服务开发支撑能力,助力中国企业打造信创。
, Y" x" k4 X2 t0 C. g% d8 r
, P8 u8 |% s* M O获取《信创微服务平台建设指南》完整方案,请点击>" K- I7 K- ?9 _3 i z; y/ ?! N o
一、打造业务系统向信创环境一键切换的能力
) @; v! x& ^4 I* X# L6 J1 p; S
3 j' q" V- o: R% r8 E信创是坚定之路,需正视他带来的若干挑战才能走好信创之路。坚持信创会主要带来以下挑战:1 G3 u$ D( ~: _7 U- v& v+ F4 v
. E, G$ [- D$ l0 e7 \; e
**1、时间紧迫性带来的挑战:**信创工作时间紧、任务重,原有的业务开发计划已经排得很满,如何让信创工作又好又快地开展,同时对原有业务项目建设推进影响最小?
1 [* R: K% t. |7 R7 e# u' x8 t' [- F6 s! |6 u! V' u$ m1 Q, M
**2、业务适配新技术的挑战:**信创建设必然引入新硬件、新软件,开发测试人员也需要学习他们吗?如何避免开发、维护信创、非信创多套代码、多个版本?2 ^6 R3 e! E R8 O
8 h" A7 g9 \6 t$ l**3、保障业务稳定性的挑战:**信创建设引入的硬件、软件需要一个过程验证对何种业务有怎么样的支撑力度,非信创与信创如何共存和过渡?如何按需在非信创和信创环境间灵活调度业务?
! L9 d$ Y5 g3 C) x$ M. r$ ~' r b4 Y* w& a) D! f, l8 r! _* i$ }5 M
**4、信创技术多变性的挑战:**大趋势下,随着时间推移,硬件、操作系统、数据库、中间件等各类新的信创组件将层出不穷的出现,如何建立起一个能够开放渐进、优胜劣汰、持续引入的能力?
# g% j Z& d3 [. D* X. W; G1 U \/ K) D
其中,现有业务系统与各层次信创技术的适配性,例如在数据库层级,信创代表技术有达梦、阿里云等,而国产数据库一般承诺兼容ANSI SQL标准,但我们代码中可能使用了大量的MySQL/Oracle的特性,如存储过程等,适配国产数据库是一个开放渐进的大工程。再比如中间件层次,信创代表技术有东方通、宝兰德等,中间件涉及的范畴比较广,目前国产中间件还是以消息中间件,SOA中间件等为主,但预期未来会越来越多。程序需要与不同的中间件进行代码级别的调整适配、测试,工作量和长期影响较大。此外,还有操作系统、服务器硬件、芯片等多方面都需要将信创适配考虑进来。9 k. k' Y/ z7 G9 _% ~2 C# m( y0 j$ `
I8 R" { [2 U8 q/ W W信创之路面临重重挑战,我们要如何实现业务系统想信创环境切换?0 O. j8 j8 ~2 N! B) Y; J) o. F
( _& n/ @- W8 y6 Y/ W. o
行云采用“解耦合 + 自动化”建立起支撑信创工作的开发平台6 L" _+ {6 |6 G
4 O8 F3 e1 W% }2 E代码是业务完整的、中立的体现。 行云计划支持实现代码与周边现存、未来之技术(信创、非信创)解除耦合。
# |0 G0 [2 U5 m+ w5 }, |
* b% ]& k2 Y" x2 _2 @& W**1、自动化构建能力:**把中立的业务代码,自动化的构建,加以适配到信创、非信创环境,灵活地在两者间根据需求调配,包括切换不同信创组件的各类场景,应做到对业务开发侧无影响,甚至是无感知。业务开发只对业务代码负责,剩下的事由平台自动处理。
( ]8 J5 f \' J/ h4 E2 v* J$ M0 g/ `! a9 g0 v) ^% Z9 m
**2、操作系统抽象:**通过容器技术隔离操作系统对业务的影响,打造适配业务需求的、精简的、优化化的基座镜像(Base Image Provisioning),无论操作系统是否信创、哪家信创,对业务无影响。
?6 L) p7 y# z; W$ N1 O4 D$ y# O8 x5 D6 L, Z
**3、中间件和数据库抽象:**通过DAPR技术实现接口抽象隔离,业务只对接抽象接口,后台对接具体的信创、非信创,或是哪家信创组件,在自动化构建和部署时决定。 当然,这涉及到业务代码的一次性调整,考虑到目前最紧迫的信创改造还是在硬件和操作系统,中间件和数据的解耦工作可以渐进式开展。+ Q! \9 q0 u, R' \4 L$ b! V0 ~
. C, l" e5 l# I/ B) x- W打造信创开发平台的收益
: G& Z* v9 S3 {% e1 D6 p& }
6 i; |' o8 |9 ?, g# I1、业务开发人员关注代码的业务实现,向信创环境的适配由平台自动化实现,在又快、又好地落地信创工作同时,原有的业务开发计划不但不受影响,反而因为有了开发平台的支撑让开发本身更聚焦于代码(而不是各类不同环境),还会让开发效率更高。
1 y* [2 h, e. T8 b( U% K
" u7 `1 ^$ J% V9 x$ {2、业务代码本身应该是“技术中立”的,开发人员聚焦于业务开发本身,无需学习甚至是关心最终交付后的信创相关技术,由平台而不是开发人员完成向不同的技术栈适配,测试人员用原有业务功能、性能指标加以测试,再转产。信创的技术实现由最有必要的、专业技术人员(运维侧)负责,这类人员也因为平台的存在而在技术组件替换、或是引入新技术时得心应手。
% D' n R% U/ U0 V6 j/ w
, w% h! i. N6 O4 R0 A' q9 V3、哪些业务先上信创、哪些后上,哪些业务需要在非信创和信创并行、平滑过渡,哪些业务可能信创环境暂时不能较好支撑,需要切换回非信创以待条件就绪再信创。为了保障业务,这些调度策略将会经常发生,再加之多数据中心的考量,有了平台帮助实现才能达成灵活高效、游刃有余。
7 e6 l- j g# C; w! V, [; }2 o9 `9 I+ i) \/ f
4、信创产品在未来层出不穷,有了平台的支撑,可以以开发放渐进、张弛有度的方式引入新技术、淘汰落后技术达成最终全面信创、稳定高效的支撑业务发展的最终目标。
: N! ~. k7 V2 k$ O+ M二、打造快速响应业务需求的跨系统编排能力3 e0 ^+ J! Z! N6 v/ s# u; s
( o2 C$ }4 q2 Z+ ~
烟囱式系统开发面临着极大的挑战
, l9 S6 B+ c1 d9 z) S, M. N
" ^: q2 T, A) @7 \6 w
8 q; U/ T C6 [+ a行云信创微服务解决方案,借鉴“桥接模式”解决该问题的思路
9 n2 D$ x8 S2 u7 c
- u$ H! ^2 j% ]: Z设计模式之桥接(Bridge Pattern)定义:桥接模式是将抽象部分与它的实现部分分离,使它们都可以独立地变化。
) j+ ] r* P1 J6 U: ^3 e
* q. C" M7 v% D" x8 S7 C- D* N· 桥接能力无需现有业务做调整,而是带外与之适配的方式,有快速实现达成的特点。, |1 Q) Z, c" Z" x
· 接收器小模块、发送器小模块以协议对接为界面,实现相对简单,又可放入备件库为未来之多场景复用。
+ ~& c, |+ ?+ X· 缓存器有信创、非信创等多种选择,技术成熟。
1 ?+ m' B. u( o- |0 V- U/ m信创微服务平台
$ [* \! W6 U& N! ~+ s& N/ d0 a: [% k
7 E% s, k& n& D& t" k* L
: I+ X% P1 ]2 W8 a1 U3 e打造通用的跨系统、跨服务间编排能力) ?5 c$ Q) k; v7 T
, g0 _ H7 c2 y" R! |! S* P
行云打造通用的跨系统、跨服务间的编排能力,以及相配套的微服务和API市场,即有解决现实问题的意义,又为技术演进的必然趋势做长远考虑,同时也是实现信创方案灵活性的必要补充。2 U+ w# W% s& ~
* @1 r, Q# A/ g
三、打造关键资源高效复用线上安全开发能力2 m& s8 e0 o1 d2 n, F0 m
0 e( E0 F+ R% T4 C9 x
线下本地开发,存在挑战:6 c) S5 {3 {) u# \& y* G$ L, r6 E. g
! p$ Y8 I3 Z6 b. b. X**· GPU等稀缺设备竞争:**人工智能等场景需要专有GPU设备的支持,传统方式下在本地开发好再上传到有GPU的服务器调试,不断反复、效率低下,在多用户需要使用GPU设备时难以协同。信创GPU出现后因为稀缺性问题更为突出。/ \* @: P: ?9 E) e3 [
( H$ R/ E+ _; t9 ^6 w& Z**· 敏感数据、系统对接:**一些敏感的数据即便脱敏后,也难以完全放在本地PC、笔记本上人手一份地开发调试,一些需要关联的业务系统接口对办公区全面开放也不现实。( w. p9 G f) y6 w9 v( S
# G3 L# I+ G; V. @" u' B**· 疫情下的远程开发:**疫情发展难以预测,远程办公、远程开发场景下的接入和使用的便利性、代码和系统的安全性都需要考虑。
; Y% y4 y! z$ K/ m8 j# G/ O6 ~ o( @7 v a7 i& D5 R/ j7 T
**· 微服务和API调试:**随着微服务和API使用的日趋增多,将不得不把内部、外部的服务和API都向办公区的PC、笔记本开放以便于开发调试,网络策略复杂且安全风险高。同时客户端在与不同版本API调试复杂度高、极不便利。+ E; e7 g' i4 w9 G! G& E% Z
( E4 g) I; D- S3 Y
行云信创微服务应用开发,采用的是Web IDE线上开发模式,可以有效解决前述挑战,如下图所示,采用Web IDE的线上开发架构,完美应对这些挑战。
* R' i6 \: s: H: ] o7 Y9 t/ y6 J* [# u* W- a
% \5 Y& B; u) L6 a* u6 c: u
8 C. Z Y6 y$ J% V G7 N7 f$ V: SWeb IDE线上开发模式,为企业带来的收益:- `1 `8 T& w6 g1 g8 k$ J3 e
4 I' S6 s6 i0 B) j! J1 x% q0 m
1、GPU等硬件资源的使用更加方便和高效。敏感数据和关键系统无需过度向办公区开放,多用户场景下开发和调试这些设备和数据更加便利。
w9 X1 P" r0 }* `& {/ k' r! M6 q, K' F+ T8 U
2、大大缩小了数据中心不必要向外暴露的攻击面,提高安全性。微服务和API的开发调试更加便利。' u( N% w" E; z- u7 `
( A% R, d% E( M% e& ?3、在内部员工或是外部供应商不能到场时,采用安全便捷的远程开发,保障项目进度。" u# L, @! e% j' s
+ e8 M" `0 ` @8 j' H: J& X, `4、与服务编排能力配合使用,开发一些胶水模块(如采用函数编程技术)更便利。8 u- y: ?7 g# j" J
( g9 F8 W% S ~4 S; g
5、未来更是有机会在编码过程中引入AI技术,让程序员写代码更加高效率、更符合规范、更加高质量。
0 |; V( I9 h* P* |' i" u) J+ a3 t四、解决当下痛点又放眼未来的统筹建设思路
& W; V7 z$ N. G3 b4 N1 m: ?8 c! q$ I4 k D+ P5 m5 Z
关于未来的统筹建设思路,银保监会指导文件带来的金融行业技术发展思路值得借鉴。《中国银保监会办公厅关于银行业保险业数字化转型的指导意见》银保监办发〔2022〕2号文件中,提到了以下四点建议:
; H9 p! d, d; }/ d+ P/ ~3 c* w3 S0 J% q+ S% x' b* t
1、自主研发:对关键平台、关键组件以及关键信息基础设施要形成自主研发能力,降低外部依赖、避免单一依赖。
9 W' v7 O! {- G6 O6 e8 m, ]) C Y
Z) Z O% {0 D3 _2、研发平台:建立能够快速响应需求的敏捷研发运维体系,积极引入研发运维一体化工具,建设企业级一站式研发协同平台。
" a3 |6 r- w2 g9 u# {9 _1 @; ~2 L% U d" Q
3、模块复用:主要业务系统实现平台化、模块化、服务化,加强企业架构设计,实现共性业务功能的标准化、模块化。1 E0 ]6 i$ G2 {/ E: \( s
/ s1 R) i5 h+ K# X( f) T8 p4、多活中心:优化数据中心布局,构建多中心、多活架构,提高基础设施资源弹性和持续供给能力。/ p4 @; R8 }0 I0 p3 c* Q7 Q
1 O4 D( U7 x6 i P J0 g
行云开放渐进、统筹规划微服务开发能力,即解决眼下痛点,又面向未来发展。
7 C# ]! g0 e y- l/ e7 I9 P! K2 ]/ L1 k0 I9 O) ], g9 k
9 L P5 a, o" }! |
6 M. z9 @" ?6 C
% ]: E- a' v9 Z- l3 q |
|