这里针对的是一般的开发类人员，从业以来看到的场景，并非针对所有，之前在一线和二线都遇到过多的类似的情况，这里表述，供一些参考。

背景

网络的一些公知感觉上有些过于浮躁，一些价值观的引导过于片面，从而引发一些误导，这里从另一个观点阐述。一般觉得工作前二三年是一个坎，这基本上很容易决定后面3-10年的工作状态和生活状态。前两三年决定的基础的能力还有思维，格局，方向还有后面的晋升等，前面开发的工作过于局限，容易导致后面的迷茫，焦虑，还有危机，如果做好自己的规划，会有比较大的转变机会。

这里所说的996并不是天天上班如此，而是在某一个时间段的高强度工作，企业对员工的一些工作要求，这种情况是很难避免的。

概述

这里并不是推崇这类似的工作状态，而是针对于自己的情况，需要进行的一些过程历练和自我驱动成长，达到自己的目标和生活状态，工作状态还有人生状态。

这里理解工作需要一定的个人喜爱，符合自己的意向，生活需要达到自足，在合适的年纪，可以有合适的生活，得到行业的尊重，工作获取到匹配的岗位和角色，但是这些获取的方式是怎么样的，一路跳槽还是有比较大的机会才能有获取，这里针对的是普普通通，按正常的，稳妥的方式考虑获取，以下从几个维度思考：

• 在职场中沉淀自己，前期做好基础能力的打磨
• 学会处事，沟通，工作，获取自己需要的经验
• 学会利用自己的优势进行晋升和高一层级脱变

这里从另一个方向进行阐述，主要考虑的是开发人员自身的发展和方向，避免在工作或者生活中产生无谓的内耗，我有我思。

过程

这里主要针对的是国内的大部分情况，IT行业当前在国际上还偏向于中低端，在这样的行情和国内规则下，要无法改变的前提，考虑运用规则转成符合自身的利益。

在职场中沉淀自己，前期做好基础能力的打磨

这里可能提到就是当前互联网中提到996场景，主要针对这个场景进行解析展开讨论。

并不是每个人都是如此，但是它确实是代表了一种现象，但是并不能代表所有，避免以偏概全，听到比较多的场景而且带有情绪特别严重的，遇到类似反馈比较多的偏向于新人或者工作生活不如意而引起的侧面情况表现，另外一种是一些公知引起的价值观偏差，比如团队内部对抗过于严重。

如果真的确实无法接受，可以换团队或者离职，现在工作机会是比较多的，并不是类似于无就业机会的情况，如果真找不到，建议先考虑一下自己的原因，又不想努力，又想要高工资，还想着责任轻松，离家15分钟等，这些先考虑下自己的情况。他人一般要么接触高一层的思维，比如博士、一流大学，要么就是在努力你没看到，这类型的人很少会有天天抱怨的，他们会朝着方向努力。

上面说得有点模糊，这里一个例子，也是常见提到的，阿里的996，层级差距也是很大的，相对来说，如果说以阿里的技术实践还有薪资待遇，还有给个人带来的社会影响力，这个过程来说，对新人的成长和提升是有一定的帮助的，应付一般的中小公司高管岗应该是没什么的，自己并不建议刚毕业两三年的人就开始养老状态，而且要了解，阿里的IT待遇远超同行的。其它类似的公司，类似于上面说的，看其它，比如晋升的机会。

这个过程是有一定的必要的，如果说，这个人刚毕业就9点上班5点下班，然后工作容易，这个也有，比如说国企、事业单位等，这些的信息部，相对会轻松很多，可以去，但是看到的，只要待个两三年，一般在IT这个行业已经很落后的了，感觉人也基本上差不多废掉了。也不反对，那你就自己努力去考公，既然又不想考，又想待轻松，遇到事情又抱怨，这类似的内耗，比较难接受。

这个过程我们需要沉淀自己，利用这个过程做为工作或者生活中的一些过度，同时获取到自己能力的提升。

学会处事，沟通，工作，获取自己需要的经验

除了上面提到能力技术以外，那部分属于硬技能，但是软技能更是磨人的，这部分人情事故，做事方法，在国内这些基本上少不了的，或者说很难避免掉，几乎在任务场合都会遇到，只是说重视的程序高深与否，小城市更注重人情，大城市可能味道没那么浓，这些基本上决定了在有技术的情况之下可以走得多远或者多高。

要了解一点，这个996有很多情况下，它是有一些附加值的，但这并不代表所有，但是在自己遇到的公司里面，都多少带有附加值，所谓的附加值有很多种，比如经验、资金、待遇、机会还有各种地位等，特别是项目初创期状态。在遇到的很多经理级和高层都是通过这层起来的，对遇到的很多中高层来说，你所说的996对他们而言，只是普普通通的工作状态，但是并没有遇到过常年996的，只是有一段时间在项目或者比较紧张的时候出现，常年类似情况的，建议换团队，太伤身了，另外一个主要的方面是过程缺少思考，对自身的提升益处并不是特别大。即使是有背景的，他同样也需要这个过程的，朝9晚5又想遇到机会，遇到的除了熬资历和真的超强以外，身边遇到的还是比较少。

为人处事的沟通和工作的沟，也只是在一到两年中遇到和学会入门，为后期的运用进行加深，在自己的理解，这些坑点遇到的越早越好。

在工作的前两年遇到类似的事情并非坏事，工作中的人情事故其实有很多门道，在前面的学习阶段，公司一般会带有容忍度和指导程度的，比如应届生在某些情况下是允许有错的，但是如果工作5年左右的，出现低级错误有的时候是很难承受的，更何况，对刚开始的前两年来说，有组长兜着，可以在思维上“放肆”一些。

这个过程往往会遇到很多人他们的为人处理思维和思路，平时多关注一些优秀人员的处理方式，类似于遇到的，很多时候，一顿饭真的可以解决很多事情或者打通一些思路，这类似的东北的一串烤串，一杯酒之类的，优秀的管理者很会利用道具来打破一些开局，这里可以注意下他们的举动，选择符合自己的方式。

学会利用自己的优势进行晋升和高一层级脱变

在前面的硬软技能之后，一两年内基本上就入门了，其它的就是加深和脱变。

经过一两年的历练，相对于一般的开发来说，是初步具备有一些技术能力和事情的处理能力的，虽然部分自己的羽翼未丰，但是也可上路。这个时候，可以根据自己的业绩或者争取到一些带有业绩的事情工作。

创造业务需要的不是一个人，而是团队一起去实现，在自己的岗位上发挥自己的能力和价值，这也是跟上面的为什么处事上需要做到一个具备条件，要得到这个主要的岗位角色并不是说自己的关系就可以，还需要一种职业素质的体现，前面努力的过程（比如某个时间段的996状态）和良好的状态过程这些都是自己最有力的证据，这些很快就会得到同行和他人的认可，即使不认可，但是面对这经历面前，一般人也会有一定的认可。

在经验和素质条件具备，这些硬实力的体现下，还有过程的沟通处事能力的自我要求下，这些是对下属还有同事具备有影响力，也是有说服力的，特别是在软件行业，在这个条件下，是很容易争取到他人的认可和信任的，包括上级或者组长，包括一些看好这个的人，即使说这家的不认可，另一家也会有认可的人（当然，这是一个机遇事件，不能说百分百，但是概率会有提升很多），常常在一个组里面，都会有一个主程或者大家认可的高级人员。

在具备这样的条件下，是具备有做事的条件和一些有能力的人共事的条件的。争取到一些团队和项目经验，提一步的提升自己，为自己的下一步的晋升做准备，这个过程往往一到两年的时间，一年是做成果，另一年是晋升适应，这样三到四年之前基本上是可以往上一个层级提升，根据自己遇到的多个团队或者企业情况，类似于这样的机遇是比较多的，比如经理级、架构级、组长级等这些是有比较大的可能性，也是符合工作年限。

在这些层级的团队和人员一起做事，做出的业务往往是容易出成果，容易成功，最后大家分享成果，不是你想这些业务成功，是这帮人一起做时候，他们有比较强大的经验，他们也考虑不能失败的，他们会过程协助你，同时指出你的问题，还有提升更好的方法和方案，会迫使你也会产出结果。

反之，如果三到四年还处于初中级开发，而缺少团队管理经验和主要的个人业绩，在某个程度上，再往上一步，可能会比较困难，一个是机遇，另一个是新人的切入，另外一个是这些过程需要的时间，太短业绩是不牢靠，而且自己的根基不稳定，很容易在后面的过程中迭倒，另一个是需要承受很大的压力。如果5-10年还属于这个状态的，一般来说基本上会遇到很多问题，比如生活焦虑、职业焦虑、待遇水平、工作压力等等。

在进入到一步点的时候，需要产出的成果点和个人业绩点，给自己晋升和提高的机会。

最后

自己并不鼓励一直高压力和高强度的工作，但是团队或者企业需要的时候，会出现类似的情况，而在这个过程中，也同步给了自己机会，给了自己的一些条件，运用这些机会和条件，给自己做好规划，转变成自己消化，是比较鼓励的。

工作前两到三年是有这个机会的，而且这个时间段做这个事情是比较合适的，就像读书是在青年时期一样，而不是跟随互联网上的，出现一些过于偏激的想法，引导，从而产生一些不好的社会现象。

以上为个人在行业见到的情况和一些见解，供参考。

这里针对的是大中小型项目的业务系统运维架构的设计，非互联网型项目，一些个人经验和思路，抛砖引玉，供参考。

背景

对一般性的运维来说，自己应该是接触几年，一二三线多个城市，政务互联网行业等都有，服务器基数在几台以几百台不等，业务微服务规模在100到几千不等，本身并不是专业做运维的（比如数据库DBA、网络DBA等，这些有专业人处理），偏向于业务服务模块的运维设计管理，以下为一些设计经验。

概述

对于长期运行的业务，有好的运维工具，更有利于业务的稳定。一般来说，业务性的运维管理从几个维度，主要是IaaS层，中间件层，业务层，运行状态层几个进行的监控管理，结合人工，手工，自动化能力角度进行设计，去掉重复的手工和低阶的运维，使业务运维偏向于高阶的思考，提升整个运维的管理能力，整体思路从以下几点，我有我思：

• 基础环境搭建
• 运维采集监控
• 运维平台维护

以上几个点为基础的能力，中间还有很多，这里偏向于设计，具体细节由专业工程师去实施即可。

架构设计

这里是整体运维管理的架构设计，从多个角度和自动化能力的管理，架构如下：

针对大的方向上面，不同的团队和业务场景会有不同的业务方案。

基本上当前主要用到工具为以下工具，其它主流性的，用起来并不觉得多顺手，比如蓝鲸，自己偏向于脚本型管理，相对比较方便，主要使用技术工具如下：

• Jenkins: 自动化能力引擎和调度工具，建议装好插件，比如Dingtalk；
• Ansible：自动化能力引擎和批量操作工具，服务器默认安装的
• Python: 一些复杂的任务脚本，可编程方便，个人感觉是对shell的一种补充
• Excel: 这里主要是对服务员和资产的管理（用过较多可视化工具，效果一般）
• Gitea: 脚本管理和运维审计，这个比较小型方便
• SpringBoot: 自定义的一些个性化功能，比如数据统计；
• Plumelog: 日志采集和统计分析（用好的话，是很强大的，也可以使用ELK）
• FileBeat: 日志采集工具，主要偏向于本地日志和物理日志，比如nginx
• Kafka: 日志数据的缓冲工具，比较强大，但是也比较消耗内存
• Prometheus: 各个监控规则和细化工具，阀值管理，这个维护rule比较长期
• Grafana: 实时统计工具（实际上Kibana也可以把它替换）
• Dingtalk: 移动端跟进和IM通知工具（内网使用grafana即可）
• Pinpoint: 链路跟踪工具（这里不做介绍，也可以使用sky，也可以不使用，其实cat更好）
• MySQL: 报表和周日报统计记录工具，也包括业务统计
• Zbox(禅道）: 工单跟踪工具（Jira也可以，比如小的团队可使用gitea的工单）
• JumpServer: 堡垒机（这里不做介绍，主要看业务场景，效果其实跟运程登陆是一样的)
• Kubernates: 容器管理工具，看团队，小项目docker-compose更建议
• Kuboard：k8s的管理工具，这个比较轻量级(kubephere太重了些)

基础环境搭建

这里根据本身的业务场景需求进行取舍，并不是一下就要上全套，毕竟资源等各个方面会有一定的限制，这里基础环境是整体的基础，包括以下几个点：

• 自动化操作引擎的搭建
• 运维日志的可视化
• 工单管理工具的安装
• 规则引擎的安装

上面的工具注意配置下unit自动启动，当然也可以使用容器，但是过程发现，有的时候容器并不是特别可靠。

自动化操作引擎搭建

自动化操作是所有的运维管理的基础能力，也是一个统一的管理思路。这里的需要安装好jenkins和gitea，这个是基础。

自动化操作主要是结合pipeline+Ansible进行管理，通过ansible的host进行的各个服务主机的操作，这里建议的变量是存放在host当中，针对不同的业务场景替换host即可，在下次另一个环境的时候，直接导入jenkins备份文件即可。

ansible的hosts可配置比较多的变量，这些方便多业务场景的改变和运维环境的迁移。

运维日志的可视化

所有的运维工具还有业务运行都需要把日志文件进行可视化统一管理显示，前期需要先搭建好日志平台，这里主要是偏向于ELK+Kafka，小项目PlumeLog替换掉kafka更合适，因为他也可以不使用kafka，比如redis等轻量型队列，不过还是比较推荐kafka，稳定性还有日志收集一流，装个单节点就可以。

也可以针对PlumeLog进行二次改造，之前就是进行了改造，毕竟Kibana的学习成本还有es的学习成本并不是每个运维人员会做的。

工单管理工具的安装

这里的管理工具指的是Zbox，即将各个工单进行安装配置和跟进，这里建议是结合Dingtalk一起，新版本Zbox对这块的支持挺好的，可实时跟进，便于项目经理和运维经理实时跟进工单的处理状态，这里比较推荐的，省去很多无谓的沟通成本。

当然，有些是不需要这个模块，比如一些比较小的项目，但是中大项目或者需要长期跟进的话，建议这块，也可以采购，之前采购过几款，费用不少，但是效果貌似还没有Zbox好。

规则引擎安装

这里规则引擎主要是prometheus（貌似目前还没有发现比这个更好的），比较轻量级，安装起来也比较快，也可以安装grafana，这里我自己不太喜欢grafana可视化，有空细调整的话也可以把grafana做得挺好的，但是自己一般是在它的官网上找到模板，没什么空去看这个“好看”的大屏，平台工具多就意味着入口很多，这也很麻烦，所以针对于自己来说，会更关注Dingtalk的信息，因为可以把这些状态统一发到上面，如果是内网不能使用Dingtalk的，Grafana是一个不错的选择，或者说Prometheus的Alerts也可以，预警信息也是一目了然的。

运维采集监控

监控采集功能即是上面工具的使用管理，主要的设计思路如下：

• 运行环境状态的采集
• 业务运行状态的监控采集
  • 运行状态巡检的管理

环境状态可视化

环境指的是服务器、中间件、容器，这里集成的主要是prometheus的功能和node-exporter等，这些使用起来较为方便，基本上会把服务器的基础状态进行采集管理，普通的状态基本上会满足，包括中间件层和容器层也一样，基于exporter进行采集， 输入到Prometheus当中即可，这里rule规则主要引用git进行版本管理，同时使用prometheus的热加载管理，结合jenkins+ansible脚本进行在线跟进更新发布。

rule脚本的管理根据运维的需求进行调整更新即可，可定时在线更新。这里的rules注意下规则的管理，一不小心有可能会造成N多的信息爆炸，那也是很恐怖的事情。

这里注意一点是，kuernates内部一般也会安装1个prometheus会更好的管理，注意不要跟物理机上的prometheus冲突就可以，当然，你也可以只用1个，但是k8s里的规则更新貌似不太好处理，会比较麻烦，之前的处理思路是jenkinsfile重新发布一下proemtheus，然后日志数据持久化。

业务运行状态的监控采集

这里主要分为两部分，一部分是前端，另一部分是后端，还有一部分是关注的业务指标。

这里前端的采集主要是nginx的采集，处理好日志的json脚本，然后通过filebeat进行采集发送到kafka中，这里的数据量大的话，推荐kafka集群，同步通过elk进行展示，这里展示的效果因人而异，实际的效果可以很酷，但是我一般比较喜欢列表展示日志。

然后就是后端数据的处理，也可以使用filebeat进行容器采集，但是k8s也会带有日志系统进行发送也可以，之前没怎么用过，对于后端的数据，使用的是springboot的配置，进行动态的环境变量处理，即配置logback-spring.xml配置，添加多环境即可，这里有一些会考虑sky，可以结合链路跟踪还有前后端请求状态，这里也比较偏向于业务项目。

有的时候，工具太重了会比较影响，所以在业务日志采集这里，会采集关注的业务服务日志，并不是所有的都会采集。另一种方式是使用容器的nfs映射能力，映射到本地存储，进行二次转移，这些主要是看项目情况，大项目的采集会比较多，同时造成很多日志压力，配置也比较高。

最后有一部分是业务指标的问题，业务指标的产生并不像日志那样，会触发错误。这里推荐根据业务情况然后进行一定的逻辑判断，这里用得比较多的方式是定时的业务计算进行业务指标输出，放到中间库里面（比如mysql），触发自动化定时巡检获取到，业务指标的监控偏向于业务运行时的跟进。

运行状态巡检管理

运行状态巡检是一个每日进行的工具，比如异常容器有哪些，异常的nodes有些，异常的链接还有端口是否开通等，一些重复性的工作而且监控工具无法触达到部分，可以通过pipeline+ansible结合进行自定义处理，比较个性化，也是有必要的。

ansible运行的结果是可以输出json的，这个方式更好的汇总的集成平台上面（集成平台这个是基于springboot开发的一个集成系统，比如简单），用于收集一些运行时状态，包括异常的统计，巡检的情况反馈等，便于下面进行周日报的输出。

运维管理平台维护

维护主要包括脚本的管理和更新维护，巡检之后进行的数据汇总和汇报，还有过程工单的跟进管理。

脚本的管理和维护

这有点个人喜好，为什么不喜欢使用一些管理平台（比如蓝鲸、ansible tower）即是如此，没有统一的运维脚本管理，包括版本的管理，操作人员的审计，权限的配置管理等，对于上面的运行来说，过程有一套脚本可个性化的配置，是有这个必要的。

这里的维护主要是结合git版本管理进行，通过pipeline来进行脚本进行任务的编排管理，基于jenkins的调度和模块化处理，基本上是满足平时的90%的管理了，平时10%的可能遇到的机率比较少，另外可移交到人工管理上。

周日报的汇总管理

汇报机制和统计机制是运维改进的一个保障，通过统计发现问题频率高的地方和影响业务地方。在收集到json数据之后，进行数据的统计分析管理，然后通过springboot自定义开发，获取到统计结果，自定义周期发送出统计结果，可按天、周、季、年等方式。

这里的开发难度并不是特别大，实际也可以通过pipeline+groovy脚本进行统计处理，但是这个必要性并不是特别大，而且安全性不是很高，成本略高，建议写个集成平台程序就可。

过程工单的管理跟进

管理制度和过程主要还是看团队的习惯还有实际情况，这里提的一个能力是工单的跟进集成，主要是zbox+dingtalk处理，然后进行汇总。

但是这里注意的是建议不要使用外部邮箱，因为发送记录会存在外部邮箱一份，而且是运维内容，这比较不安全，当然也可以申请内部邮箱，这样会更安心一些。

总结

以上为业务系统进行的运维管理架构设计，偏向于应用层，主要目标是达到可跟进，可管理，自动化等能力。以上为一些经验参考设计。

在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一样也可以实现类似的效果，只是看项目大小还有运维管理的成本。

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

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