在16年的时候开始落地服务化架构在大中小项目落地，到现在遇到过很多次讨论，基本都是使用服务化技术，这里偏向于架构设计阐述，属于个人观点，供参考。

背景

依托于容器化的普及，Cloud微服务技术当前比较盛行，在以前应该是Dubbo服务，后来慢慢建立了微服务体系，注册中心，分布式配置等各类组件，后面Nefix组件有些开始不维护，再到AlibabaCloud组件，现在很多开源框架、培训机构等依然以这些做一些宣传点。然后从自己的在多个大中小项目和落地的情况，企业运营管理，跟进行业先进技术发展，后期运维效果等多个角度思考，这无形中也会引起另一方面的方向失误。

概述

服务化本身是解决以前旧项目大，更新迭代难，耦合度高，管理开发协助难，较难支撑大并发等问题，这个在大项目上简直是福音，特别是初步切入的时候，大家都感觉看到希望一般，对这个架构难得的喜欢。

在后来几代的微服务，从服务组件的不完善到目前国内外开源组件的健全，基本上技术架构和体系都已经不再是什么难点。然而在这两年接触到的其它团队讨论中，却把这个技术架构和方式带到了另一个极端，看到的景象一般如下：

• 每个项目都微服务，业务中使用微服务，为什么要上说不清为什么使用
• 项目超细粒化划分，确实拆分出来是好维护的，而且每个就一个职责
• 架构设计比较高大上，而且看起来很复杂，很完善，devops/容器化/自动化
• 常常要搭配上一些社区很多组件，每个组件都能说一大堆好处（不否认）
• 理论论述很全，组件化，分布式，高并发，消息中间件等名词很多
• 运维管理也一样是生态体系，prometheus/grafana/skyworking/elk等
• ……

无可否认，听起来确实解决了很多问题，云原生的生态体系也非常的全的，甚至刚毕业两三年的，都可以很快的学会这套体系的技术，之前遇到的行业都在微服务（这里指的是Java技术），针对自己的项目经验和接触到的情况，看到的可能跟以上的偏差会不太一致，包含有，有自己的思考方式，从几个点阐述：

• 技术是服务于业务能力上进行阐述，避免脱离业务谈架构
• 考虑是否需要这样的技术架构，解决的问题是什么
• 取长补短，新的架构是否可以解决实际问题和业务架构设计

整体思路偏向于个人经验和落地的思路，重点在于内部的落地，我有我思。

整个过程

这里过程从一开始的业务场景到选型进行阐述观点，即从业务场景，再到团队情况，架构设计，后期维护升级几个主线思路，这里主要以实际项目经验和实际案例为参考。

技术是服务于业务能力上进行阐述，避免脱离业务谈架构

脱离业务谈技术，这个是架构师大忌，无法落地的架构不认为叫架构。

每个业务的场景并不一样，然后需要实现的效果也不一样，在这个过程实际的讨论之后，才会选定解决方案和技术架构，当然这些是基础常识。

这里针对的是团队核心型业务讨论，业务从长远来看，对团队来说除了开发，还有运维，运营，战略产品等后期的发力点，并不仅仅是一个开发框架可以或者一种开发架构能解决的，这个过程至少要考虑到3-5年，其中隐性的就结果在开始的时候不会体现，在后面的时候才慢慢展现问题和架构规划的好坏，这里针对的是团队角度，而非末端执行角度。

从某个角度来说，一般末端对架构设计的理念其实并不是特别明确，执行层需要的是经验和能力，照着顶层的架构设计去实施即可，但是对于业务架构设计的人员来说，需要考虑业务的长久运营和管理规划，包括后期的行业发展跟进，架构的先进性和可持续性，产品性能力等等，以确保团队可以长久的运营下去和保持核心的竞争力。

微服务化可以解决一部分问题，但是不是能解决所有的问题，同时也会带来过程的复杂性和技术的复杂性，同步也包括人员技术的要求等，相对于以前单体应用来说，是一个利大于弊的。

这个过程很偏重于服务划分的颗粒度，服务划分的思考角度，服务的职责能力，服务的维护团队能力，当地团队的人才储备，行业或者说市场的发展方向，内部管理层的人员管理水平，技术消化能力等等，要不然容易形成为了技术而技术，然后整体服务化之后，丢在那里而相对于之前没有太大的提升和意义。

从核心业务角度考虑，服务化之后为业务带来什么，是复杂度还是维护，或者成本降低，解决了什么问题。

考虑是否需要这样的技术架构，解决的问题是什么

新的技术引入需求，需要解决业务的实际问题，避免盲目引入。

如果某个项目，或者试点项目，建议可以从几下几个维度进行项目结果进行判断。而针对于团队的主要业务或者项目来说，微服务化这类似的变革，一般要落地，更是需要整体公司的推动，整体意识的转变，1年算短的，3-5年算比较正常，这里的3-5年不仅是业务的建设，同时也包括团队的消化和成长，成熟期的判断，需要不断的注入项目进行历练，避免今天微服务，明天单体，对团队和企业的沉淀几乎没有。

在服务化之前，一定要结合业务和场景等，考虑好为什么使用。前期面试过较过的做微服务架构设计人员，在抛出一些技术和场景问题的时候，回应出来的效果感觉不怎么好，比如以下几个问题：

“业务只有几个服务，什么要拆分，拆分的思想是怎么样的，相对于以前有什么好处“

”使用cloud，但是nginx也可以解决为什么还要引入一层复杂的业务“

”项目业务并不复杂，并发的压力可以横向扩展，为什么一定要拆分“

“工程复杂，模块化拆分和开发也可以实现，分开不是还增加分布式事务复杂性？”

“……”

接收到的回应都是五花八门了，有些可能有偏向于执行端有些偏向于技术尝新等，有些可能不了解上层的考虑（比如架构）等，但是从技术设计的角度来说，基本上看到是有些偏悲观的，可能更多的类似于听到的更多的组件化，高并发，易于维护，模块化拆分便利，互相不影响，后期升级便利等等，但是怎么样去组件化，怎么样好维护，拆分就一定方便么，增加的成本怎么考虑，后面说不清如何为业务服务。

技术架构的提升，需要很多考虑点，主流技术并不是代表就是符合。

取长补短，新的架构是否可以解决实际问题和业务架构设计

技术并不代表就是一定要那个样子，其实还可以这个样子，没人说微服务一定要cloud或者alibaba，或者nacos。

架构和业务设计尽量从简化，同时解决业务项目中的痛点和后期维护等考虑，这里提几个点，如果项目和业务来在考虑和设计提升，建议可以考虑：

• 设计的服务中能不使用分布式事务就尽量避免使用
• 把不需要的东西去掉，比如依赖n多的外部所谓好的组件
• 把层级关系尽量标明，调用关系尽量要明确
• 工程划分以业务标准为主，职责明确，模块为主，尽量少的服务
• 涉及到互相依赖的包问题尽量减少，耦合关系要明确
• ……

如果你有过程体验和感受，上面的设计就偏向于宏服务的设计思想，但是并不代表它就有标准，这里没有所谓的标准，如果非要定义一定，自己的理解，符合你的场景的那就是标准，至于使用什么技术，这个相对比较多，也比较成熟，就不过多阐述。

不过有一点滑稽的逻辑是，可以使用微服务架构来实现宏服务架构，类似于以前提到的可以使用微服务架构实现中台服务架构，只是一个架构思想的提升，类似于可以使用单体技术实现微服务架构，工具和架构融合，提升业务。

更推荐根据项目和团队等实际本地的情况，使用单体+业务+微服务架构优势的整合，类似架构如宏服务，但实际深挖远仅宏架构那么简单，一些互联网的名词出现，深挖会发出它会解决掉一些场景和方向，类似于以前的关系型数据库一样。

取长补短，来获取到符合实际业务的架构和方案，得出最优解。

总结

并不否定微服务技术，这里是不建议你盲目使用微服务，微服务技术已经有很多年，在架构设计和技术方向上，不要盲目推崇使用被技术绑架思维，而是在了解之后，以技术解决我们的痛点问题。

以实际情况为主，以团队实际能力为主，以项目实际运行情况为主，在以前没有体系之后，依然也是可以有技术方案可以实现，使用springboot/nginx/k8s一样也可以实现类似的效果，只是看项目大小还有运维管理的成本。

不希望动不动上来就是一套体系，一套方法论，而是针对问题的痛点，去选择合适团队的技术选型和技术方案，并不是方案有多优秀，而是方案有多适合，这是架构能力的体现之一。

以上为微服务技术使用的一些看法，希望可以给不一样的参考和建议。

在IT行业，自己应该是16年开始带团队，应该来来往往也有有一些团队，包括校招、社招、体系培养等，这里主要从自己带人的角度来进行阐述一些经验心得，经历有限，个人观点。

此文主要是给后期团队成员带人的参考思想和方向。

价值观

核心思想是协助和帮助他人成长，帮助团队成员创造价值和提升，激发团队成员自身的能力和潜力，保持和发展团队成员本身的善意和原则，认识现实和看清事件的本质，学会给自己做最优解。

概述

每个管理者都有自己的成长经验和带人经验，这里主要是从IT行业的进行分享，不同的岗位和角色对团队有不同的要求，不同的场景会有不同的情况，阐述主要从团队新人入团队为出发点阐述，为后期多种带人的经验输出，整体思想脉路如下：

• 了解和熟悉成员特点，包括优缺点；
• 协助成员建立正确工作观和价值观；
• 协助成员进行职业成长规划和指导；
• 协助成员提升自己对事的思想格局；

期望对他人有一定的参考价值和经验，我有我思。

过程

团队成员的融入过程，并不代表你一定要留下他，尽量协助他找到他自己的定位和方向，然后在团队中协助他进行突破，找到他在团队中的亮点，如果一点亮点都无法找到，无法能协助他人的，这个时候考虑是否需要这个人，或者他是否需要团队。

能长久的合作下去，需要有共同的支撑点，大家互相考虑取舍，会更加稳定。不希望出现公司是我家，更希望出现公司能为你带来什么的个人角度考虑，至于团队是否需要这个角色，会有负责人考虑。从自己的角度来说，更希望知道成员来工作的目的是什么，成长的愿景是什么，在一定场景下明确说明，这点是想要了解的，大家双方达到一致点，会更好合适，当然，前提是能力合适的情况下。

了解和熟悉成员特点，包括优缺点

人对外的体现是一个多种因素包含的体现，包括性格、成长、环境、家庭、教育等，最终形成他自己的特色风格，不要试图改变他，而是学会接受他。

每个人的成长经历不一样，在管理者成长过程中，有更多的经验，会更加容易判断一个人的各种因素下，针对不同的事情，可能会形成的不同的结果，或者多个结果的判断。通过这点，安排怎么样的工作和怎么样的合作，会有可预见的结果。

一旦操作不当，优点可能会变成缺点，如果安排得当，缺点也可能会变成优点，管理者要做的不是去强制性的安排，而是更加柔和的，顺其自然的按自己的预期计划去实现，这个是最好的，这个过程，成员往往是无感的。

这个需要在一定程度上观察和了解成员的特点，而这个过程不能太短，需要在一定的安排之后，查看成员的反映，根据他个人的情况会有不一样的效果，通过几次的安排，基本上就了解得差不多。

建立成员的工作观和价值观

在这个环境里面有一个规则，在你无法改变这个规则的情况下，要学会运用它，鼓励尝试使用现有的规则根据自己的情况调整成合适自己的规则。

什么叫工作观，一个例子，自己一直不鼓励所谓的“00后整顿职场”，也不建议这么处理，而是找到沟通方式，直接表达，鼓励的直接沟通，沟通不来，建议合适的时间点离职或是说明离职，道不同不相为谋而已。工作对于很多人来说，特别是工作几年的人来说，可能都已经形成自己的工作观，但是也发现很多新人和工作几年的人没有明确合适的观念，这里主要提供参考。对自己来说，很主要的一点就是能实是求是，这是对自己团队来说，很重要的一个基本素质。在不影响到个人隐私和道德观念情况下，在团队中，第一个需要的是能按实际说明，实事求是，脚踏实地。

鼓励成员能如实表达自己，这个看起来非常简单，比如在日周报里面，如实汇报，在对工作不会，如实沟通，对于不喜欢的内容，如实说明，在会议上针对问题，如实阐述，或是在对团队不满的时候，能如实说明等，需要能说出来，这个是自己所鼓励的，这样的团队相处，规避掉内部的勾心斗角，底下拉帮结派，大家相处很自然，这个是自己的团队基本原则之一。建立能表达真实的自己，而不是口是心非，当面一道，背后一面的的情况，这个是自己比较难接受的，也是不太愿意看到的。自己比较推荐的是先礼后兵的方式，在这个社会化的国情下，遇到事情以沟通为主，在无法进一步解决的情况下，再根据实际情况适当升级，怎么升级，是否一定要自己在前面，这个就比较看技巧。在没有任务技巧的情况下，建议是按实际情况表达即可。在生活各各方方面面都需要做最优解。在团队里面的发展，还有做的事情，自己要懂得为自己负责，如果自己都不关心自己，那可能更为困难。

鼓励成员能更好的尊重自己，这个听起来好像是比较不太可思议，这是相对于来说，这里可能更多的是自己看到的。职场上下级关系里面比较突出，还有新人过程比较突出，常常出现讨好型的情况，缺少主见性，过分的注重上下级的权威型，说得直白一些，带有一定的官僚气派，这个应该在实习生应届比较多。在工作里面，某个角色他所在的只是负责那部分的角色，并不是代表这个他就高高在上或者怎么样，只是在那个岗位那里，他有工作执行的权力和责任，两者是并存的。相对于自己来说，更多的会尊重团队的意愿，尊重每个成员本身的考虑点，也需要你对他做一定的尊重，这是一个平等型的关系。在自己看来，职位并无高低之分，更多的是职责，在那个职责里面，某些专业的人员他能做更明确的决定而已，认同成员需要尊重专业和技术。

鼓励成员追求自己的利益，并不需要你对工作做到什么样的付出，只需要在自己的能力范围内，完成自己的工作即可（能做好这点就很不容易了）。学会平衡自己的工作的利益关系，学会保护好自己的工作中的成果点，团队合作过程并不需要成员一味的付出，更多的是期望能听到成员的追求和期望，最简单的，比如追求高工资，追求更高岗位，这个是人之常情，也期望能表达出来，这些并不是什么难以启齿的事情。只是说要达到这个目标，怎么才能实现，方式是什么，方法又是什么，这个需要有正确性指导。比如见到有一些是觉得工龄到了就应该跟其它人一样提高，另外有些是觉得别人家的那么高，我们家的就那么低，就觉得自己理应该提高，这样的提法显然是不太推荐的，有些时候是可以，但是会有一种勉强“提高待遇“的感觉。这里比较建设的做法是把自己的业绩做出来，然后拿着业绩去做跟上级谈，做了哪些1、2、3点，有什么作用，达到什么效果可能更加合理，如果说确实达不到，这个时候是否可以考虑跳槽了。

当然还有很多点，以上只是当中很小的一面，比如遇到不公平对待，人际关系，晋升关系等，面对工作中很多的会体现出你的工作观还有价值观，这些都需要一步步的建立和提升，同时过程中的原则和底限把控，边界的把控，还有很多的。

工作观和价值观的建立，培养的是人员的品德提升和素质提升，有自己的原则和底限，团队中保持一定的原则和底限，这样能赢得团队和他人的尊重，是为日后的进一步打下基础，为后期团队成员的发展打下铺垫，也是合作的第1步，除了有背景外的，相信95%的人是在同一起跑线的，为什么有些人就是比别人快一步，自己感觉是他本身就有某些值得别人看重和欣赏的地方，可能同龄的人，没有这个体会，最后的落伍的往往就是觉得命运安排、抱怨这个那个的不合理，这些是自己所带的团队不愿意看到的。

协助成员进行职业成长规划和指导

经历和经验的限制会让成员关注点不一样，同时对前景的迷茫，需要协助他找到达到成员愿景的条件，还有过程指导，授人以渔而不是鱼。

遇到的很多开发类的人员不懂得什么叫规划，或者说怎么样进一步的给自己做好成长路线，听到的大多是跟周边的同学、朋友之类，然后口舌出来的结果，然后便去执行，亲身去验证了这个过程。好的，可能会比较有好的结果，不好的，可能就是后悔，抱怨之类的。比如一定会有人说要去考公，或者说跳槽要高工资，另一个是哪家工资高就去哪家，或者去北上广深一线就业，这些都是很多人的方向，之前遇到成员就做了，包括我自己也是一样的。

从两个方面看，其实大的游戏规则已经划定了，这个是社会资源的分配，就比如你正面跟清华北大的拼学历，一般人是拼不过的，去跟富二/三代类型的拼财富，这也是不现实的。每个人的人生出来就是一张自己的牌面，怎么样把自己的牌面打好，这个我对规划的理解。

针对于团队成员来说，在没有充分的判断力之下，针对于管理者来说，应该针对于成员的情况，给适当的职业成长规划建议，这个听起来有点类似于别人说画饼的感觉。其实没错，就是在规划，从成员个人的意愿提供更好的机会和建议，同时提供合理的操作空间，在遇到一些问题的时候，能给他们思考的时间和成长消化的周期，这个在接触的很多项目里面，是有这个机会的。

比如一个简单的例子，接触到很多开发想做架构师，但是怎么做到架构这一步，实际上他是不知道的，或者有些成员想走管理者，但是管理需要哪些条件和素质，很多他也是不清楚的，这个时候，根据项目的过程，提供一定的机会安排，这个对团队负责人来说，是很容易的，只要稍微的调整一下角色的分工，还有人员的跟带，就有可能提升成员一个较好的成长土壤，在这个过程中同步做些协助和指点，一般来说，只要他有兴趣，加上过程的成就点和鼓励点，他会主动积极去做的，成长起来是比较快，这个时候你会发现，一些优秀的人他会自己管理自己。但是这也是一个双面，如果想要让成员走入另一条路线，也同样可以做到，这就需要管理者需要一定良好的品德（也就是第1点提到工作观和价值观），切勿有害人之心。

当然，并不是每个Leader都有照顾到所有人，同时了解到每个人，这也是上面提到的，更希望成员能自己提出自己的期望，然后协助他做好这步。这步是有几个比较突出的点，一个是培养他的感恩之心，另一个是有助于自己的管理，同时也可以协助他更好的融入团队等.

所以为什么第1个章节提到培养工作观就是这样，这是互相促进的。因为我帮助了你，你有提升了，更好的帮助到公司，心态上就会有一定的改观，在做事情上就慢慢融合，事情就会做得更好，做更好了，然后共同进步发展，这是一个互相成就的关系，管理者在成就他人的同时，他人也在成就他。反之例子，很多成员在困惑中成长，工作的职业道德和他本身生活的限制会让他在这个环境里面1、2年，这段时间里面会迷茫不知所措，形成他本身自己的戾气，表现出来就是这个不满那个不爽的，自己成就感不强，甚至带有怨气，最后无法找到自己的定位，然后就不断的跳槽或者说生活没有成就感，存在一些消极等，这最后形成的只是说是团队和他本身的双损，这是不建议的。

协助成员提升自己对事的思想格局

协助成员接纳自己和认清一些行业发展，从多个角度去思考，获取到自己的最优解，建议要考虑是否是做这个角色，是否能区分角色。

工作场合从自己理解的角度出发，本身偏向于利益关系，在遇到问题的时候，自己要能为自己选择到自己最合适的路线和解决思路，获取到自己的最优解。这好像是很多人员都会，或者很多都在做，但是发现，在付出和收益成本两条线上，缺少一些更深层的思考。

这里主要从IT行业的角度来说，其它的行业自己也没有思考过。会发现，很多成员的认识里面，只有前端、后端等角色之分，但是它本身的作用是什么，为什么要这么做，然后这么做有什么好处，然后目前更好的解决方案是什么，现在主流的方向和技术是什么，并没有更多的思考，然后就是张口Java，闭口vue之类的，在沟通处理问题的总会绕不开这个话题，当然，这个也对，每个人都有一门是精通的，但是什么叫精通，并不是是每个人都会说得清楚 ，或者理解。怎么样才叫专家，自己要学习到什么程度，这些很多都没有进行过思考。最后的体现呢，更多的是在某个岗位上陷入一个死角，然后只会这个，其它的就谈不了了，这里所说的其它，指的是同一个IT领域的。

上面说得可能有些抽象，我们来个例子。最近在关注测试这块，在准备进一步的优化测试流程，所以我们就拿测试角色来说。可能是自己在二级城市，遇到的测试偏向于业务型测试，说白一些的就是点点，然后进行业务测试功能测试，然后测试除了点击以外的呢？还有哪些？有些可能会说，还有测试报告、测试用例、bug跟进反馈、环境管理、版本管理等，然后呢？

到这步的时候，应该很多部分人员都不会再有进一步的思考，好像上面都已经很多了。换个角色，期望看到成员思考的角度是从怎么进一步优化测试的角色，比如怎么优化测试流程，进行整个流程的梳理优化提升效率，进行一些自动化脚本的管理，然后解放手工，另外过程中保存下文档还有使用示例，方向后期人员的学习的培训，同时找到过程中的卡点和重复工，形成基础的公共模块，在这些工具都整理之后，思考别人怎么快速上手（先别说他人，先思考自己怎么管理和方便后期），然后把规范梳理出来，形成一套测试流程和测试脚本，同时测试示例，方便自己后期查找，再在这个过程中记录下问题，项目中实践，一步步的整理出可用的内容还有过程中的问题点，再看看别人怎么做，优秀的团队怎么做，再进一步的进行优化整理测试方案，形成一套自己的测试标准和工作流程。你会发现，慢慢的会了解行业的最先进技术和方案，这样会发现行业测试发展的痛点，在没有解决方案的情况下，自己尝试查找自己的解决方案。

过程会发现，涉及到架构、团队、规范、自动化、平台、解决方案等，整体考虑的格局就已经突破了一般测试人员，在最佳在实践下，就会在某个场景下有自己的测试最优解决方案，向行业进行输出自己的实践经验。成员在过程中会说自己不会或者没有时间，其实这点是可以解决的，这个时候需要懂得利用管理资源，如果上级人员不会，那就好办了，你会了，那机会就更多了。这个过程基本上前面1-2年可以把技能（也就是所谓的技术能力）和工具熟练，同时积累一些项目经验，后面3-4年进一步加深了解，形成资深，那后面的几年就是晋升和更高级的打怪。

再回到我们的话题，上面的只是测试的例子，还有开发、运维、项目管理等等，这些其实都可以进一步的加深深入思考，规避掉自己范围的局限性，无形中会提升自己。而做为团队的管理者来说，这是一件高兴的事情，也就是上面提到的第2点，协助成员的提升和规划还有发展（前提是他有意愿或者潜力的情况下），这会更好的促进团队的成长和发展，同时促进大家的提升和公司的发展。

总结

以上为带团队的一些经验总结，不同的场景不同的经验不同的方式，工作并不是主从关系，本质上是合作关系，主从关系是表现，是为了更好的合作和更好的配合，达到团队目标的更好的方式。然后再配合上各种管理手段、工具等，比如软件工程、Scrum、一些考核机制等，这些相对来说，只是工具手段，运用起来不难，只是有工具了，他会协助管理，形成一种流程和规范，这些就比较简单了。

在这个过程中，会有约束和规则，学会运行现有的规则和环境去操作，符合大家的利益，这是管理需要考虑的部分，而个体上需要考虑自身(管理者也包含个体）。每个管理都有自己的成长经验和带人经验，这里主要是从IT行业的进行分享，不同的岗位和角色对团队有不同的要求。

以上为自己的经验分享，希望能给一些参考和建议。

此文为国庆主题，内容是在工作和当前行业接触过程中，在十四五发展的规划，还有当前国内外行业环境下的一些心得体会，这里属于自己个人观点。

背景

这个是一个国内外发展变革的时期，这里从两个维度交待背景，分别是国际和国内。

当前国际环境格局变动，俄乌战争，美国技术封锁，中国一路一带发展等，这些大国的发展，影响着整个国际社会的变革。乌克兰战争的爆发，欧美的对俄的制裁，对俄的封锁，更是体现出国际环境技术自主发展的重要性，各个国家意识到和平统一，谋求共同发展，光刻机、芯片等限制，突出体现基础核心产业的重要。中国一路一带的发展，朋友圈在世界扩大，前期上合峰会的发展，更体现出亚太地区的经济的发展变化，整体亚太版块的结合更加紧密。

国内而言，中国制造业、互联网在国际名列前端，核心技术不断突破，数字化和AI的发展，更加将技术自主更加深入人心，国产化的技术在国内兴起，已经形成趋势，云技术和数据治理技术的普及，使得当前平台化，自动化成为主流，核心的技术产品和业务的中台化，在国内已经形成不可挡的方向，形成平台化的产品在各个头部互联网企业体现，比如物联网、人工智能、数据中台、城市大脑等，阿里云、腾讯云、华为云的云计算发展为各行各业赋能，形成大中台提供技术，前端团队形成交付模式，新的软件发展模式已由传统进一步转变提升。

概述

在国家崛起的这个时期，输出自己的技术能力，贡献自己的能力，这是自己对强国的一种体现。

基于以上背景，国家政策的实施，身在软件行业中的个人或者团体，都有体会在国家崛起的时期，针对于我个人的定位和发展，输出自己的能力和一些力所能及的发展贡献。在这个过程中，虽然国内有一定的发展，但也会体会到国内外软件的差距，不仅仅是芯片，在基础软件的建设，行业软件的建设同样还需要努力，互联网还有各个技术依赖于基础软件，行业软件需要各个高新技术的支撑。

自己本身处于行业软件，在这块上的体会比较深刻，国内千万个行业的发展，每个沉淀需要很长的周期时间，需要不断的去提升，打磨提升行业软件的服务能力，解决方案能力，结合更多的主流技术进行提供出更好的解决方案和用户体验，科技创新，提升业务本身的价值性和软件服务的优势。

当前专注在公积金发展上，自己从自身的了解和体会上，从三个角度和多个思考体会点，阐述自己的观点，我有我思：

• 公积金行业的发展：行业的发展和现状的思考，了解当前的问题和现状，明确本身行业的需求和发力点。
• 企业团队的定位：团队角色的定位，自力能力的认识，明确自己的角色和适合自身的发展点。
• 发挥自我价值的思考：需求和自身的匹配，让自己更加专注和发展，提升自我价值和更深入行业思考。

为了更好的描点阐述和自己从其它行业的思考，下面的标题做了缩减。

行业发展

行业和发展需要新一代人的深入，新的思维和新的理念的介入，体现行业的创新和服务的提升。

公积金行业自己接触的并不是特别长，但也不是很短，总下来的几年，看到的了解的，多少有些体会，这里陈述自己的理解，同时也结合自己在其它行业经验进行的陈述。

相对而言，行业软件的发展由原来10年前的单体架构已经提升到的分布式架构，公积金本身大部分或者多个城市属于传统现状，而这也是本身业务性质的稳定性要求，还有业务范围本身等原因。公积金的业务属于比较稳定型（这里的稳定指的是核心业务）和各个对接的第三方、外围等，而个性化的区域和业务，还有流程等，偏向于局面地区，而这个也形成了各个区域不同的门槛。同时业务的复杂性还有行业的沉淀性较强，对一般性的人员接触，都是在有自我公积金之后才进一步的初步了解，基于这个，人才的积累还有资深层面上，是有可预见性的，人员并不多，类似于电商行业，可能很多人都特别了解它的业务，而相对理解公积金业务的，达到资深的，其实行业内还是比较少的。

基于以上种种情况来说，政策、区域、人才、还有个性化等特殊性，造就一个局面，就是公积金业务相对传统，大部分来说，使用的软件技术还有创新性上就比较少，整体偏向于传统行业。

另外在行业竞争的这多家里面，能有大城市大项目经验的还是数得过来，而这个针对当前团队来说，是有一定的优势的，而基于以上的局限性，也有对手尝试打破的，比如产品化的提升，产品化的输出再加上互联网的思维打法，在全国性铺开。当然接触并不是很深入，但是从整体还有各个反馈来说，虽然铺开，但是也同样分散开来的手掌，在一定程度上，也会有受限，毕竟全国的业务就是那么多，那么大。在江浙一带的，由于互联网的优势，有一些突破，但是表现貌似并不是那么突出点。

近几年软件行业的发展非常迅速，人工智能场景的不断突破，技术还有数字化的不断加持，传统的公积金行业受到刺激，大家都在不断的找方向，这个过程中，也是期望能看到不一样的试点和服务突破，很可惜，当前还没有遇到。

针对于以上种种，也许还有很多。结合我们团队在做公积金业务中台，中台化的建设和思维，这个是自己特别看好的，看好的原因并不是单纯的架构，而是一种行业的变革，一种全新的软件模式。

这里也提出自己对业务中台的理解，中台化的思维更像是一种公积金操作系统，进行基础的操作系统安装，把公积金的核心业务的元数据和主数据进行沉淀，其它的软件像搭建积木一样的让各个团队去建设，形成一套公积金业务中台产品，而这个就是产品能力的输出，把这个概念传输到全国，加上一线城市大项目的落地案列，在可把控的操作下，形成产品化，形成一体化，加上中台特有的架构形成数据沉淀，形成标准，更好的输出到全国，有数据，有AI，有场景，形成进一步的公积金业务大脑，形成新的服务概念，新的业务创新输出。

业务中台是一个土壤，在这个上面积累和形成人才、业务、新产品、人工智能等的成长，最终形成行业多个插件或者产品形态的插件，形成一套行业解决方案，甚至后期可以结合元宇宙，足不出户，就可以办理公积金业务。当然，这套也可以复制到其它的行业，促进其它行业的发展，或者扩展到海外（就是不知道海外有没有公积金）。

整体行业的现状，结合自己的理解还有对行业发展的期望。

团队定位

一个人有自我清晰的认识，就能在团队找到定位和促进团队的进步，发挥自己的优势。

行业的发展需要人才的支撑，这里的人才并一定要达到什么条件，这里主要是表达符合时代的发展需要，在对应的岗位，对应的工作，对应的能力范围内，力所能力的输出自己。

在对行业的现状的做的同时，清楚的定位自己，能了解自己的能力还有所擅长的，喜欢和热爱自己的工作，在这个点上发光发亮，能我所能，达我所达，促进某一项的发展，在国家发展和崛起下，也是一种价值体现。在软件行业接触差不多近7年，在接触的团队还有方面的认识下，自身也有不断的认识。从初始的兴奋，到迷茫，到发现不足，到努力，到再认识自己，在这个成长过程中，需要感谢到很多，也同步建立自己的工作观和人生观，学会面对，学会去做好一件事，同时也学会团队的相处，更加清楚自身的限制。

这个过程中的打破，更多的是在公积金行业，首信团队中的体会，团队的互相成长，包容，还有协助，同时还有互相感恩，当然，还有硬技术，这些有部分除了自己有努力和领会，但是在我的感觉更多的是团队给的，对首信公司，对我自己而言，本身就带有比较浓厚的个人情感，在这个基础之上，会更多确定自己的输出还有团队定位。

在一个人拥有的一个热爱的心态之后，在对事情还有做事上就会提出自己的想法还有主动性提升，这点自然自己也有。我更期望的是能在团队中发挥自己，更多的让大家看到，看到的不是我，而是为团队推进出成绩，让大家看到我们的发展，提升热情，提升目标。我始终相信在这样的氛围下，大家会共同进步，共同努力，一起发展，进而推进公积金行业的发展，这是我所想看到的，也是想做的。成果是团队的，大家的，也是我的，也许这个就是自己所追求的定位。

有了方向，定位然后就很清楚，在未来的3-5年（自己只能看到这么远）中，当前技术还有中台产品建设输出的情况下，我更多的是协助和提出自己在过程中的经验，在团队大的目标下，结合自身具备的一些技术优势，一些成长经验进行传输他人，发展和落地中台的内容，协助两广区的同事解决过程的技术问题，也在过程中自我学习新的技术内容，新的解决方案，推进和解决我们的问题，提高前端业务的技术能力，同时也期望自己的本身经验，对中台产品的进一步打造和输出，形成我们公积金业务的标识和品牌，这个是我们的进步，这是行业的发展的一个进步。

即是自己所喜欢的，也是自己所热爱的，更是自己所期待的。

自我价值

每一代都有每一代特有的使命感，期望能为团队做好一些成果，在回想的时候能自己回味下。

能有所期待，即有目标，同有方向。在公积金行业的发展历程上，也许我们只是一个过客，一个不会有人记得的角色，更是一个默默无闻的程序员，但是这并不影响我们对行业输出我们自己，并不影响我们自己的价值，在对应的岗位上，做好自己，做好我们这一步需要做的，承接上一代人的理想，承接上一代人的精神，我们有自己特有的角色，特有的使命。

在中华民族百年复兴里面，中国改革发展40年，已经建立了一个又一个奇迹，这个过程，一波又一波的洪流，一代又一代人的推动，他们在兢兢业业的岗位上，付出自己的青春，付出自己的汗水，付出自己的知识，成就新一代人的梦想。

在前一代公积金业务中，无数的公积金人给我们建立好了基石，他们打下了公积金行业的基础，从公积金的制度初起立，在这个制度还有国民住房中发挥着重大的作用，解决了一代人的住房问题，这是我们所能看到的，也是全国在受惠的，正是他们的努力，开创了行业，推进了行业，促进了国家的发展和进步，促进了中华人民的安定和繁荣。这些成果和业绩，是值得我们尊重的，也是值得我们学习的。

而在我们这一代，不管是技术和经验，能力都在稳定的阶段，也是发力的阶段，更是在创新的阶段。在新一代公积金业务中台的建设，结合当代最新的技术还有科技使命，在国家的数字化，还有科技进步发展下，融合更多的新技术，比如云计算、大数据、人工智能、自动化能力等等，为业务的发展和创新提供了条件，新一代公积金业务中台为这个打下了基础，促进了行业的更进一步的发展和提升。在这个建设过程中，不仅仅是一份工作，更是一份事业，一份使命感的存在。在只是这一波洪流里的，在未来的5年里面，自己也在思考输出自己的力所能及，促进新一代中台的发展，进而公积金行业的发展，这是自己想看到的，也是想留下的。

总在有一天，回想后面的5年，自己曾经做过这样的一个事，可以有自己单独的回忆，自己能回想或者说得出来的事情和成果出来，这也许就是自己追求的价值。

收尾

以上是自己的过程和思考，仅以此文进行自我勉励，自己可以得到更多的认识，吸引更多同类型的人一起共同努力，共同发展和创造价值。在自己这勿勿的三十年里，在软件行业里面，我们需要很多突破，同时也更加需要有人可以提出自己的观点，尽自己微薄之力推进行业软件的发展。

在国际大变革的情势下，我们在软件技术的自我发展，国家在不断的输出自己的国际影响力，一带一路建设，上合组织的影响力，整个亚欧大陆正在连接，中国正在崛起。千年华夏，百年屈辱，党改革开放40年，中华民族伟大复兴的时期，在国家不断前进的同时，身处这个时代的我们，在自己的努力和行业岗位做好我们自己，通过这样的方式表达是自己对复兴强国的贡献。

最后，在这个发展的过程，同时也是对我们首信人的期望，不会遗忘自己是国人在当代的使命，输出自己的技术能力，贡献自己的能力。

在从事IT行业以来，在业务建设过程中，一直无法规避的问题，就是基础层建设，建设消耗的人力物力极大，在做架构带团队的时候，这个更加体现。

此文档为ACP能力输出方向和解决方案之一。

概述

国产化的趋势是方向，更多的业务建设还有数字化整合国产化，安全化的要求，比如国密要求，数据上链（区块链）等，同时也产生出新的行业问题体现。ACP中台的解决和规避数字化建设的相关问题，这些由中台层进行完善和考虑，整体架构如下：

方案描述：

• 利用中台的优势，进行多方和各种基础层的规避，做好角色责任划分；
• 利用中台的优势解决国产化、数字化、安全化的问题；
• 让数字业务建设过程中，对相应的基础层建设透明化。

常见基础层问题

当前行业发展和国家的战略要求，在数字经验上，提到自主可控，国产化等要求，这几块上，国产化的建设当前涌出很多，特别明显的芯片、数据库、操作系统等，这几块对数字经验，数字业务上提了进一步的要求点，列了以下几点：

• 网络安全和各种加密的问题
• 云平台兼容适配的问题
• 多国产化数据库的兼容
• 国产品系统和前端兼容的问题
• 数字建设第三方问题
• 新技术框架的整合和融入
• 新旧技术衔接问题
• 数据采集成本的问题
• 数据抽取存储，治理运营的问题
• 自动化运维监控的问题
• 自动化版本管理业务集成的问题

问题描述：

• 网络安全和各种加密的问题，包括Xss、国密、SQL注入等问题，国家安全数据规范的问题，第三方接口数据安全的问题
• 数字建设第三方问题，包括常见的安全问题，比如信息泄漏、SQL注入、数据加密、逻辑漏洞、各个框架安全问题（比如log4j）、数据安全、文件上传等
• 新技术框架的整合和融入，新技术的升级问题，兼容问题，新旧升级过渡问题，升级成本的问题考虑等
• 云平台兼容适配的问题，包括国产操作系统、第三方云平台、私有云、IDC问题，CPU问题等
• 前端兼容的问题，包括新前端兼容，浏览器兼容，移动端的兼容，接口的兼容问题，接口规范定义的问题
• 数据库的兼容，包括国产数据库不同版本，数据库迁移的问题，第三方数据库，缓存的兼容问题，后期数据标准的问题
• 新旧技术衔接问题，包括人员学习成本，学习案例成本，文档梳理成本，业务升级投入成本的问题
• 数据采集成本的问题，包括业务数据来源的问题，数据规范不统一的问题，数据质量的问题，数据源不一致的问题，数据沉淀的问题
• 数据与业务打通的问题，包括数据整合梳理提交流程，数据上传流程，业务数据共享的问题
• 数据运营的问题，数据与业务整合计算的问题，数据反馈协助业务运营的问题，数据标准和资产管理问题
• 运维监控的问题，这部分主要包括传统手工化运维、日志监控采集、，日志数据安全保留周期、异常信息预警、运行监控等；
• 自动化版本管理业务集成的问题，这部分主要包括数据安全的处理、备份、定时巡检的处理、结果预警、自动扫描、安全巡检等。
• …..

使用中台解决方案

这里主要考虑的是几部分，从封装，规避，服务几个角度进行阐述，大的指导方向是中台层建设封装，业务技术的卡点规避，中台层提供的服务，从职责上进去划分，主要包括如下：

中台层的封装

中台层的封装主要是规避底层的技术能力和内部的衔接，这里包括多个层面的基础层建设，这里使用了中台层的技术架构工具实现，输出成为基础的公用业务建设平台层能力，通用型的业务建设能力，规避和上一层能力的重复性。

数字中台提取出公共的业务服务，封闭统一的业务接口，为业务上层的集成，提供基础能力，让业务中台建设和业务组件集成，不需要再考虑底层的技术偏差问题，同时提供出源码型的交付，业务针对于自身的情况，提供出基础的中台服务。

研发中台产品架构图，结合团队/组织架构/数据/应用/运营整体体系的产品规划，整体产品架构图，这里主要输出的能力方向如下：

业务建设卡点的规避

中台层服务能力

这里服务能力包括几个方面，这里常见的列了几个常见的点，主要几个点：

• 团队组织的服务能力，过程的建设指导能力
• 过程中台能力的支撑解决服务能力
• 技术架构的设计和业务整合的服务能力
• 业务建设过程的文档输出和示例输出的服务能力

上面基本上是基础的团队型服务能力，这些基础的能力，解决了支撑体系的问题，但是在基础层输出另一层，即是实际的输出表现，这里主要体现的是产品能力：

• 研发文档型的输出，这个是最直观性的
• 接口和数据共享型的的输出，这个是直接的基础中台层能力
• 工具型的可视化输出，这个是基础中台层的过程能力

在服务体系和直接产品型为基础提供了落地的保障，使更加站在业务型建设上进行的规划和思。基于以上的服务，进一步的推动业务建设，主要体现几个点：

• 让业务建设专家专注于业务架构的输出
• 业务团队专注于业务的建设和思考，更多的时间周期在业务的问题上
• 提高业务创新水平和服务水平，提供业务质量水平
• 更多的加强在客户关系维护和需求分析和落实上，提供更优质的客户服务
• 更好的业务产品体验，在商务和市场上更高的抽取出来
• 高层级的人员和管理者可以抽取，进行更多战略型的思考和发展

其它

• 暂无

此文章为技术输出章节，为中台技术支持体系的基础支撑架构方案和思路，主要面向中小型团队的支撑架构，大型或者超大型团队建议自建

概述

近几年常见的主流技术名词很多，主流新的方向也很多，比如DataOps、GitOps，DevOps、Scrum（敏捷）、ChatOps、PaaS、CloudNative（云原生）等多个主流的名词，当然还有其它领域的，比如GIS、SmaryCity（智慧城市）、元宇宙、数据中台等，这些主要听起来很高大上，确实很高大上，但是回到实际团队，这些又解决了我们什么痛点，价值性对自己有何作用点，体现在哪儿。

接触过一些团队，都有这些规划，也有这些实施的方向，走向也很明确，但是操作起来可能是另一回事。

基础能力

建设过程

后期扩展

其它