> Java > java지도 시간 > 자바 아키텍트의 길 - 전류 제한 기술과 다양한 프로그래밍 언어

자바 아키텍트의 길 - 전류 제한 기술과 다양한 프로그래밍 언어

巴扎黑
풀어 주다: 2017-06-26 11:48:44
원래의
1976명이 탐색했습니다.

 현재 시중에 나와 있는 프로그래밍 언어는 주로 객체지향적입니다. 객체지향은 가장 기본적인 것부터 시작해야 합니다. 예를 들어, 나는 24살에 결혼했는데, 그렇지 않고 어떻게 객체 지향 프로그래밍을 할 수 있겠습니까? 그러다가 결혼하자마자 아이를 낳게 되는데, 상대방이 도망가면 어쩌죠? 생성과 소멸에 비용이 많이 든다면 자식을 갖고 객체에 대한 참조를 계속 유지하는 것이 좋습니다.

왜 어떤 사람은 입을 열면 오랫동안 말을 하는 반면, 어떤 사람은 가끔씩만 말을 하는 걸까요? 내 관찰에 따르면, 거의 똑같이 잘 일하는 두 사람은 미래에 더 잘 발전할 것입니다. 구체적인 사례를 통해 그 이유를 느껴보자.

친구들과 이야기를 나눌 때 정말 몇 년 전에 Renren에 나온 사람들은 항상 약간의 기술적인 괴짜 정신을 가지고 있습니다. 사람들은 귀하의 비디오가 어떻게 저장되고 재생되는지 묻습니다. 저는 콘텐츠와 메타만 작업하고 나머지는 저와 관련이 없다고 말했습니다. Tian'er는 죽을 때까지 대화를 나누었고 그의 패턴이 자리를 잡았습니다. 내가 하는 일에 대한 개발 플랫폼이 있다면 여기에는 동영상 업로드도 포함됩니다. 먼저 초기화를 위해 클라우드 스토리지 인터페이스를 호출하면 비디오 미디어 업로드 URL이 반환됩니다. JS 측은 미디어 조각을 URL에 업로드합니다. 네트워크가 중단되거나 브라우저가 닫히는 경우 이력서 업로드 인터페이스를 호출하여 새로 반환된 URL을 사용하여 업로드를 계속할 수 있습니다. 이력서 전송 인터페이스는 총 파일 크기와 지금까지 수신된 파일의 크기를 전달하여 전송을 계속할 조각을 결정할 수 있습니다. 클라우드 스토리지는 다른 부서에 있고, 클라우드 트랜스코딩 부서와의 소통을 담당합니다. 클라우드 트랜스코딩은 미디어를 다양한 형식으로 변환하는 작업과, 샘플링이 어떻게 이루어지는지, DRM 디지털 권한 관리는 어떻게 되는지에 대해 설명합니다. 어떻게 하느냐는 클라우드 트랜스코딩 부서의 책임입니다. 다양한 DNS 노드에 배포하기 위해 내부적으로 어떤 전략을 사용합니까? 스케줄링 부서가 비디오 웹사이트의 가장 소중한 대역폭을 절약하기 위해 어떻게 스케줄링하는지, 구체적인 세부 사항은 잘 모르겠습니다. 클라우드 트랜스코딩 부서에서는 변환된 다양한 코드레이트와 영상 URL을 MQ 형태로 우리에게 전달하고, 우리는 이를 데이터베이스에 저장합니다.

그리고 다시 묻습니다. MQ에 무엇을 사용하나요? 나는 아파치의 qpidd에 대해 이야기하고 있습니다. 음~~, 모르면 대화가 지루해지거든요. 따라서 MQ는 토끼 mq와 유사하다고 말할 수 있으며 AMQP 고급 메시지 대기열 프로토콜을 기반으로 합니다. 이는 회사의 통합 클러스터로, 설치와 배포가 매우 편리하다고 합니다. 주류 프로그래밍 언어도 지원하므로 사용합니다. 주로 부서 간 통신이기 때문에 주로 편의와 통신 비용 절감을 위한 것이므로 메시지 본문을 json으로 먼저 압축한 다음 base64로 압축합니다. 우리는 또한 protobuf의 바이너리를 사용하지 않습니다. 왜냐하면 문제가 발생하면 바이너리는 읽기 어렵고 자체 설명이 부족하며 문제 해결이 쉽지 않기 때문입니다.

  높은 동시성 서비스에는 서비스 중단, 다운그레이드, 격리, 전류 제한, 비동기 RPC 등과 같은 몇 가지 비상 계획이 있어야 합니다. 서비스 중단, 다운그레이드 및 격리를 위해 모든 사람은 Netflix의 오픈 소스 분산 서비스 탄력성 프레임워크인 Hystrix를 사용하는 것을 선호합니다. Hystrix는 트래픽을 제한할 수도 있습니다. 그러나 우리 서비스는 이를 구현하기 위해 성숙한 토큰 버킷 알고리즘인 Guava의 RateLimiter를 사용합니다.

  서비스 조절은 매우 간단한 문제입니다. 우리의 코드는 몇백 줄에 불과하지만 비교적 완전한 디자인 아이디어 세트를 포함하고 있습니다. 목적은 특정 전략(예: URL, 플랫폼 소스, URL + 플랫폼 소스)을 기반으로 세분화된 비즈니스 전류 제한을 구현하는 것입니다.

  

 이 인터셉터는 현재 제한 보유자의 단일 인스턴스를 정의하며 구성된 정책을 따르고 제한으로 구성된 맵이 반환됩니다. 해당 키와 RateLimiter를 요청하는 인터셉터입니다. 인터셉터가 한계를 초과했다고 판단하면 처리를 위해 컨트롤러에 전달되지 않고 오류가 직접 반환됩니다. 세밀한 속도 제한을 위한 RateLimiter인 url과 같은 요청 유형입니다.

물론 이러한 애플리케이션 수준의 현재 제한 외에도 IP 세션 공간, 요청 빈도 및 동시성에 대한 일부 제한을 nginx 수준에서 구현할 수도 있습니다. 네트워크 공격이 발생하면 먼저 운영 및 유지 관리 수준부터 문제 해결을 시도하세요. 수준이 높을수록 서비스에 미치는 영향을 최소화할 수 있기 때문입니다.

  좋은 소프트웨어 아키텍처는 시스템 품질을 충족하고, 수혜자가 일관된 목표를 달성할 수 있도록 하며, 계획 프로세스를 지원하고, 시스템 개발을 위한 지침을 제공하고, 복잡성을 효과적으로 관리하고, 재사용 기반을 마련하고, 유지 관리 비용을 절감할 수 있습니다. 갈등 분석을 지원합니다.

 대부분의 아키텍처나 프로그래밍 언어는 프로젝트에서 나옵니다. 예를 들어, C++의 창시자인 Stroustrup이 이 언어를 설계한 원래 의도는 C 언어가 불합리한 초기화 매개변수로 인해 심각한 프로그래밍 문제를 일으키는 것을 확인하는 것이었습니다. 이 문제는 청소 중에도 발생합니다. 그렇게 하고 꾸준히 하면 정말 성공할 거예요. 그러나 모든 것에는 형성과 발전의 단계가 있습니다. Java는 이전 버전에서 성능 문제에 대한 불만이 제기되어 왔으며 모든 Java 버전에는 성능 개선이 수반되므로 JVM을 업그레이드하면 무료로 성능 이점을 얻을 수 있습니다. 세부 사항을 생각하면 final 키워드가 떠오릅니다. 초기 버전에서는 final 키워드의 일부가 인라인으로 호출되어 스택 안팎으로 매개변수를 지속적으로 푸시하거나 팝할 필요 없이 함수를 직접 확장했습니다. 성능 오버헤드를 유발합니다. 그러나 함수 본문이 클 경우 상대적으로 큰 공간 오버헤드가 발생합니다. JVM은 1.5부터 최적화되었으며 최종 키워드는 더 이상 성능에 그다지 중요하지 않습니다. 알고 보니 회사에 아주 친절하고 좋은 아이디어를 가진 동료가 있었습니다. 그는 "항상 내 아이디어 중 일부를 노트에 기록했다가 시간이 지나 보면 그 당시 아이디어 중 하나만 고수해서 했고 성공했다는 걸 알게 된다"고 말했다. "내 생각엔 그가 생각하는 것보다 성공과는 거리가 더 멀다고 생각한다. 왜냐하면 그가 가진 것은 아이디어뿐이었으나 실행에 옮기지 않았기 때문입니다. JDK1.0이라는 아이디어만 있는 것 같지만, 성공까지는 최소한 jdk1.5는 멀다.

 Python은 작은 코드 크기, 낮은 유지 관리 비용, 높은 프로그래밍 효율성으로 유명합니다. 하지만 낮은 유지 비용과 높은 프로그래밍 효율성에 최적화되지 않은 프로그래밍 언어는 얼마나 될까요? 그래서 사람들은 나에게 검색 엔진이 이미 불타고 있다고 묻습니다. 미래에 정말로 자신만의 장점을 만들 수 있습니까? 내가 말할 수 있는 것은 시도하지 않으면 어떻게 알 수 있느냐는 것이다. "인생은 짧습니다. 저는 파이썬을 사용합니다." Python의 이러한 기능은 여자를 데리러 더 많은 시간을 확보할 수 있지만 인생은 너무 짧습니다. Python 저자의 광고 문구는 Python에 활력을 줍니다. 실제로 Python의 단순성은 메모리 재활용에서 볼 수 있습니다. 참조 계산을 사용하므로 순환 참조 문제가 없습니다. 저는 Renren에 있을 때 Python 프로젝트를 했습니다. 우리 리더가 나 혼자 8명 분의 일을 한다고 하던 시절이 있었다. 나는 전체 웹사이트의 모든 유지 관리 작업 외에도 온갖 종류의 새로운 일을 맡습니다. 이런 성격 때문에 남들이 나한테는 정말 닥쳐올 일이 전혀 없고 나 자신만 창피할 뿐이다. 당시 저는 일한 지 4년이 안 됐고, 프로그래밍을 한 지 2년이 채 안 됐는데, 일을 시작한 지 2년이 채 안 됐을 때 일본어 번역가로 일했다고 하더군요. 우리가 누구에게나 갈 수 있는 이유. 어느 날 베이징에 와서 선배들과 함께 이화원을 방문하고 있었는데 갑자기 Renren.com에서 인터뷰 전화를 받았는데 전화를받은 사람이 나에게 여러 가지 기술적인 질문을했는데 내 대답은 모두 "아니오"였습니다. 다른 쪽 끝은 매우 좋았고 중요하지 않다고 말했습니다. 마지막으로 전화 반대편에 면접관이 있었는데, 저에게 일본어로 무슨 일을 했는지 물으셨고, 주로 제가 일본어를 아주 잘하신다고 만족해 하셨습니다. 그 결과 저는 Renren.com의 교량 엔지니어가 되었습니다. 예전에 개인 프로필에 썼던 글에서 네티즌들에게 언어 재능이 있다고 욕을 먹었다고 썼던 기억이 나네요. 그런데 뉴소프트에 있을 때는 다들 나에게 언어 재능이 있다고 했고, 그렇게 생각하는 게 익숙했어요. .. 그냥 당연하게 여기고 있는 것이지, 광고할 생각은 없습니다. 저는 Python도 모르고, 오픈 플랫폼이 무엇인지도 모릅니다. 하지만 오픈 플랫폼의 사장이 메이투안으로 떠났기 때문에 오픈 플랫폼 전체의 유지 관리를 제가 직접 맡았습니다. 그런데 이 사장님은 정말 대단한 분인데, 칭화대학에서 사업을 시작하고 런렌에 와서 메이투안에 가서 P4가 되었고 지금은 사업을 시작하고 있습니다. 어느 날 남자 친구가 나에게 칭화 동창회 사진을 보여주며 "이 사람이 당신의 전 동료인 것 같습니다"라고 물었습니다. 나는 "예"라고 말했습니다. 그는 "옆에 앉으신 분은 우리 사장님이시다"고 말했다. 글쎄요, 제 남자 아이돌은 아직 개선의 여지가 많은 것 같아요.

 저는 과감히 이 오픈 플랫폼을 유지합니다. 그러면 Bubble Fish 게임이 일본 플랫폼에 연결됩니다. 이 게임은 Python으로 작성되었습니다. 당시 이 게임은 매우 인기가 많았습니다. 게임 회사는 매우 바빠서 연결할 시간이 없었기 때문에 우리에게 돈을 지불했습니다. 우리는 코드를 가져와서 직접 연결할 수만 있습니다. 당시 Renren은 내부 기업가 정신을 좋아했습니다. 우리는 해외 사업부였고 처음부터 수익성이 없었습니다. 연결을 했는데 게임파티에서 연결비 100,000을 주고 나머지는 게임몫이었는데 수입이 얼마나 됐는지 모르겠어요. 하지만 당시에는 이것이 우리에게 유일한 수익성 있는 프로젝트였습니다. 파이썬은 정말 배우기 쉽습니다. 낮에는 웹사이트를 관리하고, 밤에는 접속을 하고, 파이썬을 공부하고, 문서에 접속하고, 결제 접속 부분을 일주일 만에 끝냅니다. 테스트 환경을 충전할 수 있습니다. 그런데 온라인으로 진행하는데 문제가 있었습니다. MM 운영 및 유지보수팀에서 구축한 정식 환경을 실행해보니 뭔가 문제가 있었습니다. 저녁에는 모두 집으로 돌아가고, 저는 그곳에서 혼자서 온라인 환경 작업을 했습니다. 나중에 설치된 도구 중 한 부분의 버전이 잘못되었음을 마침내 발견했지만 세부 사항이 기억나지 않습니다. 6년 전에 그런 일이 있었습니다. 그래서 저는 파이썬을 해봤지만 파이썬을 모릅니다.

 Java와 C++ 사이에는 동적 메모리 할당과 가비지 수집 기술로 둘러싸인 높은 벽이 있습니다. 벽 밖의 사람들은 들어가고 싶어하지만 벽 안에 있는 사람들은 나가고 싶어합니다. Java에서는 그렇게 캐주얼할 수 없습니다. 즉, 메모리 할당 매개변수를 최적화하는 것입니다. JVM 매개변수 최적화에 관해 말하면 실제로 가장 일반적으로 사용되는 것은 모두가 알고 있지만 심각하게 받아들이지 않는 것은 초기 최대값과 최소값을 설정하는 것입니다. 힙의 값을 동일한 값으로 설정하여 힙 자동 확장을 방지하고 처리량 감소 및 지연으로 인해 발생하는 새로운 세대 및 이전 세대의 전체 GC 크기를 조정합니다. Minor GC를 포함하여 JVM의 거의 모든 GC 작업은 세상을 막아야 한다고 합니다.

 마지막으로 외국 웹사이트를 모두에게 추천합니다. 분석을 중심으로 실용적인 도구와 튜닝 기법을 소개하는 경우가 많습니다. 대표작으로는 He

가 있습니다

위 내용은 자바 아키텍트의 길 - 전류 제한 기술과 다양한 프로그래밍 언어의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

관련 라벨:
원천:php.cn
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
최신 이슈
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿