Interpretação das tendências da arquitetura nativa da nuvem.
Desde o desenvolvimento da arquitetura de software, ela experimentou o processo de evolução da arquitetura única, arquitetura vertical, arquitetura SOA para as atuais tecnologias nativas da nuvem, como microsserviços e grades de serviço. O desenvolvimento de tecnologias nativas da nuvem é imparável. ainda ser um tema quente no futuro. Além disso, com a aceleração da transformação digital, as empresas usarão a nuvem em um novo nível, e a arquitetura nativa da nuvem e os aplicativos nativos da nuvem continuarão a evoluir iterativamente.
Assim, com o apoio de tecnologias como a nativa da nuvem, quais são as tendências dignas de atenção no campo da arquitetura em 2022? Como a nuvem nativa suporta o futuro da arquitetura?
01
Processo de Evolução da Arquitetura de Software
Nuvem nativa
InfoQ: A arquitetura de software passou da arquitetura monolítica para a arquitetura SOA e depois para a forma arquitetônica representada por microsserviços nativos da nuvem. Quais são os principais nós intermediários?
Zhijian: Falando sobre a nuvem nativa de hoje, acho que ainda precisamos revisar a história para entender do que se trata.
Em 2000, não havia conceito de virtualização e o que todos viam eram máquinas físicas;
A VMware nasceu em 2001, mas nessa época ainda era uma máquina virtual;
Mais tarde, em 2006, a Amazon lançou a plataforma IaaS (Infrastructure as a Service) AWS.Na época, a ideia era transformar CAPEX (custo de investimento de capital) em OPEX (custo operacional). Ou seja, não preciso comprar muitas máquinas, mas comprar na nuvem depois de usar;
Em 2009, Heroku propôs PaaS. Nessa época, deixou de ser entregue por máquinas virtuais, passou a ser Buildpacks, passou a ter o conceito de conteinerização e um conjunto de regras para aplicações de 12 fatores;
Em 2010, surgiu o OpenStack. Na verdade, ele usa código aberto para implementar IaaS. O objetivo é competir com a AWS. O bloco de construção que ele constrói ainda é uma VM;
Em 2013, o surgimento do Docker trouxe mudanças relativamente grandes e, nessa época, a entrega passou a ser um contêiner.
O Cloud Native mencionado hoje foi proposto pela primeira vez pela Pivotal e posteriormente definido pelo CNCF (Cloud Native Computing Foundation) estabelecido em 2015.
Na verdade, podemos ver claramente algumas mudanças ao longo do processo: de mainframes, servidores para VMs, Buildpacks e depois para contêineres, as unidades isoladas estão ficando cada vez menores, tornando-se muito pequenas. O objetivo mais importante disso é fazer o desacoplamento. Você pode ter muitas ideias sobre o Cloud Native, mas acho que o ponto principal é qual é o núcleo do Cloud Native. Pelo que entendi, acho que todo software tem um ditado sábio, chamamos isso de dividir para conquistar, e pode também pode ser chamado de solução, acoplamento ou alta coesão e baixo acoplamento. Por meio do desacoplamento contínuo em microsserviços, toda a interação é mais ágil. Em vez de serem acoplados como os aplicativos monolíticos anteriores, é difícil coordenar e entregar.
Outro elemento importante do Cloud Native é o não lock-in, ou seja, evitar o lock-in da tecnologia. Partindo da definição de normas pelo CNCF, o CNCF não vai dizer diretamente que algo é um padrão, eles vão considerar isso como um componente chave, e dizer que esse componente é amplamente adotado e reconhecido pelo nosso CNCF. Desta forma, mais pessoas irão utilizá-lo, e sabendo que este software será mantido por muito tempo, naturalmente será padronizado, e o benefício desta padronização não é um bloqueio. Acho que pode ser resolvido de diferentes dimensões .entendê-lo.
Do ponto de vista do fabricante, você pode escolher com flexibilidade diferentes provedores de nuvem; a outra é que para engenheiros, se você fizer desenvolvimento de negócios na plataforma da empresa A, é muito provável que não tenha como usá-la depois de sair da empresa R. A vantagem de não aprisionar é que os funcionários não ficarão presos a uma empresa de tecnologia. Desde que você domine a tecnologia Cloud Native, sua posição poderá circular no mercado de talentos.
Yanlin: Há pouco Zhijian falou sobre isso da perspectiva de toda a indústria de software. Deixe-me explicar brevemente meu entendimento da perspectiva da indústria.
A atual tecnologia nativa da nuvem, incluindo a forma de arquitetura de software, tem muito a ver com a Internet 1.0, 2.0 e 3.0. A primeira era da Internet 1.0 eram as páginas estáticas. Naquela época, o conteúdo carregado pela maioria dos sites era relativamente simples e um único aplicativo podia ser resolvido basicamente com a adição de um CDN. Interação, mais interação e mais renderização têm requisitos gerais mais altos de tecnologia Aplicações monolíticas não podem mais atender às necessidades de negócios cada vez mais complexas. Neste momento, entramos na era do SOA e dos microsserviços; depois disso, toda a indústria passou por uma mudança relativamente grande, ou seja, a Internet móvel. A chegada do a terceira era apresenta requisitos mais altos para desempenho em tempo real, incluindo "aquisição ativa, push passivo". A quantidade de informações adquiridas e renderizadas em tempo real é maior, e todo o sistema de TI também experimenta um crescimento explosivo nesta fase, o que exige maiores requisitos para sistemas digitais.
Com o desenvolvimento de toda a computação em nuvem, na verdade, mais com o desenvolvimento da nuvem, por volta de 2015, pelo que acabei de dizer, a generalização e a padronização estão basicamente tomando forma gradativamente. Depois de 2015, todos os tipos de conteinerização na indústria, como Docker, K8s e Spring Cloud, estão surgindo nesta era, o que provavelmente é o caso.
InfoQ: Depois de tantos anos de mudanças na indústria e na indústria de software, em que estágio a arquitetura nativa da nuvem se desenvolveu agora?
Zhijian: Acho que olhando para isso hoje, pode-se dizer que a arquitetura nativa da nuvem foi amplamente aceita por todas as esferas da vida.
Tomando o Service Mesh como exemplo, a aceitação do Service Mesh cresceu muito no ano passado. A razão pela qual usamos o Service Mesh como exemplo ao falar sobre a arquitetura nativa da nuvem é porque o conceito geral de nuvem nativa foi amplamente aceito. Os problemas que outrora o Service Mesh foi questionado, como o desempenho, hoje são gradativamente aceitos.A aceitação não significa que o problema de desempenho tenha sido totalmente resolvido, mas que todos saibam fazer bom uso de seus pontos fortes e evitar seus pontos fracos.
A questão que muitas empresas consideram hoje é como implementar a tecnologia nativa da nuvem. Acho que a nuvem nativa, seja um conceito ou um padrão de design, é uma combinação. Não direi simplesmente que o desenvolvimento nativo da nuvem atingiu 50% ou 60% de todo o processo, e não usarei esse pensamento para analisar, mas se podemos ir primeiro para o nativo da nuvem. -tecnologia nativa, também posso seguir esse ritmo para seguir em frente.
Acho que o bom é que todo o público tem uma boa consciência e compreensão da tecnologia nativa da nuvem e, em seguida, a tendência geral da nuvem nativa também é otimista e florescente.
Yanlin: Deixe-me falar sobre meu entendimento sobre esse assunto. Em primeiro lugar, do ponto de vista da tecnologia de software, você pode ver que este ano, incluindo Alibaba Cloud e todas as outras nuvens, estão falando sobre contêineres em qualquer lugar. Na verdade, os contêineres se tornaram a Este tipo de infraestrutura, com o desenvolvimento dos próximos três a cinco anos, pode haver mais contêineres do que rodando apenas no ECS.
Do ponto de vista dos microsserviços, como estamos fazendo um planejamento de dois anos recentemente, você deve ter visto alguns dados importantes, como o salário médio dos programadores chineses. O salário médio é o custo de mão de obra, que na verdade é muito maior do que o de TI. Poder de computação custo e custo dos recursos. Os contêineres são mais sobre custos de agendamento de recursos e custos de operação e manutenção, enquanto os microsserviços são mais sobre custos de P&D e custos de colaboração. Porque se houver muitos co-construtores em um código, a eficiência será muito baixa. Portanto, o primeiro problema é que a mão de obra e a eficiência estão se tornando cada vez mais importantes e, com a intensificação da concorrência em todo o setor, você terá uma vantagem se correr rápido e perderá essa oportunidade se correr devagar. indústria é "peixe rápido come peixe lento".
Outra coisa relativamente nova nos dados que me preocupa é a distribuição etária de todo o programador. A geração pós-anos 90 tornou-se a força central na construção da economia digital. Seu modo de colaboração e estilo de trabalho não são os mesmos da geração antigos membros. Eles gostam de um modelo de colaboração mais ágil e independente, e os microsserviços são, na verdade, um modelo de colaboração mais alinhado com eles.
Atualmente, do ponto de vista de toda a indústria, os microsserviços se tornaram uma escolha popular. E também podemos ver dois outros dados: o primeiro é que, do ponto de vista de toda a indústria, os microsserviços têm uma taxa de crescimento anual de mais de 20%, o que significa que dezenas de milhares de empresas em toda a indústria estão transformando os microsserviços a cada ano; A segunda é que, além das empresas de Internet que realizam a conteinerização e a transformação de microsserviços, muitos setores tradicionais, como varejo, assistência médica, finanças etc., começaram a passar por atualizações digitais uma após a outra, e os microsserviços têm uma aplicação mais ampla espaço em toda a sociedade.
De outro ponto de vista técnico, seja um aplicativo único, microsserviço ou futura grade de serviços, Serverless, etc., todos têm seus próprios cenários de aplicativos. Hoje, isso pode ser devido ao aumento dos custos de mão de obra e aos jovens em geral idade exige colaboração. Mais livres e independentes, os contêineres e microsserviços estão se tornando cada vez mais importantes nessa tendência geral.
InfoQ: No processo de nosso bate-papo agora, também vimos muitas audiências expressando sua aprovação e também mencionamos alguns casos de implementação. Os dois professores têm algum caso de implementação relevante para compartilhar?
Yanlin: Na verdade, existem muitos casos de implementação. Deixe-me dar alguns exemplos que podem ser compartilhados com o mundo exterior.
Nos últimos anos, a Laidian Technology concluiu toda a transformação tecnológica nativa da nuvem, incluindo conteinerização e microsserviços, e obteve melhorias relativamente grandes na eficiência de P&D e na utilização de recursos. Agora eles chegaram ao segundo estágio da nuvem nativa. O grande problema agora é a governança de serviços, como off-line elegante e não destrutivo. Ao mesmo tempo, eles também enfrentarão o problema de alta disponibilidade, como sua cena real, on-line e integração off-line. Requisitos mais altos para estabilidade on-line exigem um sistema de alta disponibilidade, incluindo limitação de corrente, downgrade, fusível, reversão e escala de cinza de link completo. Eles chegaram a esse estágio no momento e também estão em um nível relativamente alto em termos de governança de serviços, representando um caso em que algumas empresas tradicionais e a Internet têm uma interseção.
A outra é a SKECHERS. Eles também acompanharam a transformação digital e sabem que a economia digital já é uma tendência imparável na China. Se não aderirem a essa tendência, podem ser eliminados. Ele também nos contatou para preparar todo o sistema intermediário. Ele rapidamente reutilizou a arquitetura técnica intermediária de Ali em poucos meses para construir todo o seu sistema de varejo. Claro, ele também encontrou alguns problemas no processo. Ao trabalhar em um sistema de microsserviços, todo o seu sistema anteriormente tinha acesso multiterminal a máquinas POS, Web e App, incluindo algumas arquiteturas tradicionais, e parte dele era uma nova arquitetura de microsserviços. Nesse processo, o novo gateway nativo da nuvem resolveu o problema. Questões de segurança de intranet para extranet, como gerenciamento de certificados, proteção da Web, autenticação de segurança, etc.
Além disso, a Skechers também fará uma grande promoção, o valor de pico é várias vezes o normal, eles reutilizaram o sistema de alta disponibilidade de Ali, desde a entrada até o back-end, e fizeram uma limitação de corrente de link completo de ponta a ponta, mecanismo de downgrade e fusão, garantir alta disponibilidade em todo o processo de transação. Ele também realizou um drill em todo o sistema de teste de estresse de link completo, e o drill foi bem-sucedido com um mês de antecedência, suportando todo o sistema de comércio eletrônico da Skechers que negociou no dia do Double 11.
A construção de um sistema desses leva alguns meses, o que é um bônus que todo o nativo da nuvem traz para todos. Vou compartilhar brevemente esses dois casos.
Zhijian: Deixe-me acrescentar brevemente que a implementação da arquitetura nativa da nuvem hoje não é um número pequeno, já são milhares de conceitos.
Se você costuma prestar atenção em toda a indústria, pode ver que as grandes empresas de Internet quase conhecidas não estão dizendo que estão explorando, mas já estão usando em profundidade, acho que não há dúvida sobre isso.
InfoQ: Quais problemas serão encontrados durante esse processo ou na implementação e aplicação de novas tecnologias e como lidar com eles?
Simples: quando nos deparamos com novas tecnologias, o “novo” não é o maior problema.
Só acho que o surgimento de cada nova tecnologia nos fará repensar a dívida técnica deixada por cada empreendimento durante o processo de desenvolvimento. Incluindo a implementação do Service Mesh no Alibaba Group antes, o que sinto mais doloroso não é se essa tecnologia é nova ou se você não pode fazer isso, mas se você tem que gastar muita energia e tempo para lidar com o fardo histórico primeiro.
Portanto, no processo de aterrissagem, um dos maiores pontos problemáticos que vi foi, na verdade, o custo da transformação, incluindo a migração da arquitetura anterior para a nuvem nativa e a possível divisão de serviços. Porque a arquitetura nativa da nuvem não significa simplesmente que você mova para o contêiner para resolver o problema, mas que devemos aproveitar esta oportunidade para fazer microsserviços, pelo menos em termos de eficiência.
Yanlin: Deixe-me falar sobre alguns dos meus sentimentos específicos na prática. Em primeiro lugar, todos devem ter uma atitude aberta em relação às novas tecnologias. Por exemplo, seja a transformação de microsserviços ou containers, ela muda não só a arquitetura de software, mas também a arquitetura organizacional. Por exemplo, quando exportamos a arquitetura de software de Ali para algumas empresas tradicionais, descobrimos que toda a organização de Ali é plana e os microsserviços também são planos e distribuídos, portanto, a eficiência da colaboração de todos é relativamente alta, o que é um modelo de desenvolvimento ágil. No entanto, muitas organizações ainda estão na forma de pirâmides e a eficiência da colaboração interdepartamental será relativamente baixa. Obviamente, à medida que a arquitetura do software muda, a estrutura organizacional também muda com a arquitetura do software, o que você pode entender aos poucos.
Então, quando todos derem o primeiro passo para resolver o problema de mentalidade, eles realmente enfrentarão alguns problemas um após o outro, porque não há bala de prata na indústria de software e não há arquitetura onipotente. Por exemplo, a arquitetura de microsserviço é realmente uma equipe de mais de 10 pessoas e mais de 5 subsistemas, só assim haverá maior vantagem na produtividade geral. No processo de transformação do próprio microsserviço, todos têm mais dúvidas sobre até que ponto meu sistema foi desmontado? Acho que "um master e um backup" é uma faixa mais adequada, se a desmontagem for muito pequena, vai trazer mais custos de coordenação e custos de operação e manutenção. Claro, isso não significa que, se for desmontado com precisão, definitivamente não funcionará. Alguns cenários de negócios se desviam do tipo de cálculo linear e podem ser desmontados com mais precisão se forem mais leves. Isso requer especialistas experientes para fazer a segmentação de domínio .
Especificamente falando sobre a divisão de microsserviços, o primeiro problema que encontrei na época foi o posicionamento. Depois dos microsserviços, você verá que os logs foram para mais de uma dezena de máquinas. É muito caro visualizar todos os logs e o diagnóstico custo de problemas Também é muito grande. Agora, o rastreamento de links da indústria, incluindo APM, monitoramento e alarme são soluções para problemas neste campo.
Além disso, vimos um dado, ou seja, 70% dos containers são microsserviços muito fáceis de implementar. Porque depois dos microsserviços, a implantação do seu aplicativo é mais fina e detalhada, e o custo de operação e manutenção aumentará. Uma grande parte do contêiner resolve o custo de operação e manutenção por meio do modo de automação e obtém um efeito complementar. Através da evolução dos containers, resolve-se um problema de custo de implantação após a divisão dos microsserviços.
No geral, o que posso sentir lentamente é que o limite para usar todo o contêiner e microsserviços é muito menor do que antes. Hoje, por meio do desenvolvimento de código aberto e computação em nuvem, o limite dessas tecnologias foi reduzido e o restante pode ser mais tomadores de decisão procurando o momento certo. Por exemplo, sei que o negócio vai crescer de forma explosiva e a complexidade vai aumentar, quero evoluir a arquitetura cloud-native e resolver o problema, provavelmente assim.
02
Perspectivas para Tendências Futuras da Arquitetura
Nuvem nativa
InfoQ: Você pode falar brevemente sobre o que é a arquitetura multi-cloud?
Para simplificar: em nossa opinião, uma das forças motrizes mais importantes da nuvem nativa é evitar o bloqueio, e também é algo com o qual as empresas se preocupam e esperam ter uma padronização.
Se for multinuvem, haverá alguns desafios para os clientes atuais gerenciarem multinuvem. Acho que isso será um processo. Desde o início, todo mundo fala em ir para cloud-native, multi-cloud e cloud híbrida. Esses dois são, sem dúvida, o conteúdo principal do cloud-native, e também o tornará mais e mais conveniente para os desenvolvedores usarem essa tecnologia. , isso é feito de uma perspectiva centrada no desenvolvedor, então definitivamente haverá tecnologias e produtos relacionados sendo lançados um após o outro no futuro, incluindo alguns agora.
Além disso, entendo que a curto prazo as pessoas podem pensar que não é tão fácil de usar, mas acho que vai ficar cada vez mais fácil de usar. Com certeza esse será o foco de todos os fornecedores de nuvem, porque o foco do nosso desenvolvimento ainda é ver como podemos resolver os problemas dos clientes, quais pontos problemáticos ajudam o cliente a desenvolver melhor seu negócio.
Yanlin: Multi-cloud pode ser chamado de forma diferente por diferentes fornecedores, como nuvem cruzada e nuvem híbrida. Nosso lado enfatiza mais a nuvem distribuída. O que posso sentir é que todos no setor têm ideias diferentes sobre por que escolhem várias nuvens.
A situação no exterior pode ser que haja algumas necessidades de alta disponibilidade, mas na China todos esperam ter recursos mais baratos e combater guerras de preços. Overseas espera aproveitar as vantagens de cada nuvem, como IA big data, Google Cloud é mais forte e AWS é mais forte no campo tradicional da IDC, para que possam ser usados de maneira mista. , negócios off-line estão no Google e assim por diante.
Dou esse exemplo para dizer que para a maioria dos fabricantes deve haver um custo para cruzar a nuvem. Algumas empresas nacionais podem querer escolher vários fornecedores de nuvem e negociar alguns descontos, mas o resultado é que a complexidade da operação e os custos de manutenção e gerenciamento aumentarão depois de cruzar as nuvens. Entendo que a indústria doméstica de Internet tem investido muito nessa área. mão de obra para suavizar.
InfoQ: Coletamos algumas perguntas da comunidade antes e gostaríamos de perguntar quais novas formas de arquitetura de software aparecerão nos próximos cinco anos.
Simplicidade: O que exatamente é a arquitetura? Acho que precisamos dar uma olhada primeiro. A arquitetura que entendo é composta de três elementos. O núcleo é o conceito. O segundo é a relação entre o conceito e o conceito. Acima do conceito e relacionamento O terceiro elemento imposto são as restrições.
O surgimento do nativo da nuvem é, na verdade, um tipo de prática arquitetônica. Esse tipo de prática é baseada nos problemas que vimos e enfrentamos no passado, revisitando e refletindo, quebrando e dividindo os conceitos anteriores e, em seguida, reformulando esse conceito e, finalmente, formou as Best Practices (melhores práticas) sobre as quais falamos hoje, incluindo muitos padrões de design, como Sidecar, Operator e assim por diante.
É impossível dizer que não haverá novos conceitos arquitetônicos nos próximos cinco anos, mas pessoalmente acho improvável que seja subversivo. Se você deseja subverter a arquitetura nativa da nuvem, deve primeiro aplicar a tecnologia nativa da nuvem até certo ponto e, em seguida, encontrar uma situação em que ainda haja uma busca mais extrema. Quanto às mudanças, é normal que novos conceitos sejam propostos.O desenvolvimento da indústria é a criação contínua de conceitos pelas pessoas. Este é justamente um fenômeno e um estado natural do desenvolvimento tecnológico.
Yanlin: A menos que a computação quântica faça barulho, acho que a era distribuída existirá por muito tempo antes que essa era chegue. Então, na era distribuída de longa data, podemos sentir algumas tendências acontecendo.
Com contêineres e microsserviços, os negócios se tornam sem estado. Se a flexibilidade do agendamento flexível for maximizada hoje, o serverless será possível no futuro. Do peso leve de nosso cliente de middleware na arquitetura técnica deste ano, o lado do negócio evoluirá para ser sem servidor, porque o negócio agora está se tornando cada vez mais sem estado. Com a conclusão da infraestrutura subjacente e a disponibilidade de recursos elásticos, existe a possibilidade de evolução ascendente, mas, de nossa perspectiva este ano, é mais fácil usar serverless para algumas tarefas de front-end, como computação offline. Acredito que com o avanço contínuo da tecnologia básica, incluindo a tecnologia de aceleração de hardware, muitos dos principais fabricantes têm planos para sem servidor. Antes, todos falavam sobre sem servidor em termos de arquitetura de aplicativos. Agora, por exemplo, o armazenamento de mensagens tem produtos correspondentes sem servidor, portanto, sem servidor Pode ser uma ideia técnica no futuro.
Além disso, o que posso sentir é abaixo do contêiner, mais preocupado com o DevOps, para resolver a eficiência da operação e manutenção, a primeira metade da nuvem nativa para resolver o problema do Ops, é o problema da operação e manutenção, no futuro mais para resolver o problema do DevOps, é assim Tornar o P&D mais eficiente e desenvolver iterações mais rápidas. É claro que, nesse processo, o middleware, incluindo os microsserviços, pode resolver mais questões de segurança padrão, credibilidade e estabilidade.
03
Compartilhamento da experiência de crescimento do arquiteto
Nuvem nativa
InfoQ: Muitos programadores encontrarão alguns gargalos quando passarem de desenvolvedores comuns a arquitetos. Os dois professores têm alguma experiência no crescimento de arquitetos que possam compartilhar com você?
Zhijian: Na verdade, há muitas coisas para falar no campo dos arquitetos. Deixe-me primeiro falar sobre meus pensamentos e compartilhar brevemente alguns pontos. Yanlin pode fazer suplementos.
Em primeiro lugar, o primeiro ponto de ser arquiteto é ter a busca pela tecnologia, você precisa ter algum acúmulo em tecnologia, e a busca pelo design de software, que é o que chamamos de "A Beleza da Arquitetura".
O segundo ponto é saber mudar de perspectiva e olhar as coisas de diferentes ângulos. Meu maior sentimento como arquiteto é como olhar o que estamos fazendo na perspectiva dos usuários, clientes ou usuários. Quando você olha as coisas da perspectiva dos usuários ou clientes, você encontra algo completamente diferente.
Do ponto de vista da minha própria comercialização no ano passado, tenho muitos sentimentos. Quer se trate de desenvolver e entregar um produto para os clientes ou fazer um módulo interno, como olhar para isso da perspectiva da outra parte descobrirá que um termo técnico com o qual estamos familiarizados parece natural e simples, mas clientes ou usuários não. pense assim.
Pessoalmente, acho que o mais importante é a atualização contínua do pensamento.Do foco nos indivíduos ao foco em equipes e organizações maiores, é um processo de avanços contínuos. Para ser um bom arquiteto, você deve ter a capacidade de abstrair continuamente, ser muito pragmático e ter pensamento de produto e pensamento de negócios. Quanto mais alto for sua cognição, você descobrirá que a tecnologia é apenas uma parte, mas o que quero enfatizar é não achar que a tecnologia não é importante, é justamente a tecnologia básica que é sólida, para que você possa ter confiança para fazer um avanço.
Yanlin: O que Zhijian acabou de dizer é muito bom.Mudar de perspectiva é um obstáculo que muitas pessoas não conseguem evitar quando mudam de programadores para arquitetos, PDs e líderes. Em seguida, adicionarei os seguintes pensamentos do meu lado: costumo entrevistar, então combinarei isso para falar sobre algumas coisas com as quais estou mais preocupado.
Em primeiro lugar, no que diz respeito à tecnologia básica ou ao desenvolvimento de software, prefiro pessoas curiosas.Se você se interessa por tecnologia, pode continuar se aprofundando na tecnologia. Somente movidos pela curiosidade podemos nos desenvolver profundamente e ir mais longe.
A segunda é tomar a iniciativa de assumir responsabilidades no trabalho. Também costumo dizer aos alunos da equipe que talvez você não consiga lidar com isso e eu os ajudarei a fazer isso juntos. Nesse processo, você pode obter mais recursos e ajudar e crescer mais rápido. Muito crescimento é pular para um nível mais alto e desafiar coisas mais difíceis, para que possamos continuar nos exercitando e pensando nos problemas de um nível mais alto.
A terceira é a dimensão do pensamento. Há pouco Zhijian mencionou a perspectiva do usuário e a perspectiva técnica, e há outra perspectiva que também é mais importante, ou seja, a perspectiva geral.
Por exemplo, se um funcionário recém-contratado olhar para um problema e desmontá-lo, ele não pensará muito. Se ele conseguir desmontar 10 problemas em 5 requisitos, 5 problemas já atingiram um nível superior e ele poderá aprender com esses 5 requisitos .Descobrir os irracionais e evitá-los ao mesmo tempo.Isto leva ao pensamento de produto, e reequilibrar o cronograma para completar as necessidades razoáveis remanescentes exercitará a relação entrada-saída e o pensamento prioritário. E quando você concluir um produto inteiro, continuará a colaborar com front-end, front-end, operações etc., e sua capacidade será desenvolvida gradualmente no processo de colaboração. Da mesma forma, subindo está a capacidade de coordenar recursos mais periféricos e assim por diante.
Para resumir brevemente, após 2-3 anos de emprego, o acúmulo profundo da tecnologia central é muito importante, e somente com profundidade podemos ir mais longe; depois de uma tecnologia sólida, o segundo ponto é cultivar o pensamento do produto, o pensamento do produto é muito importante, não faça apenas tecnologia; Depois de pensar no produto, a terceira coisa a fazer é a colaboração entre as pessoas a montante e a jusante. Para ser um arquiteto, você precisa lidar com várias funções para fazer as coisas; quando a colaboração é concluída , o problema a ser resolvido é a capacidade de liderança e planejamento para o futuro, esse requisito será relativamente alto.