팔다리에 산소를 밀어 넣은 것처럼 문제가 해결되었습니다.
Problems solved like Oxygen pushed out to limbs
근접성은 처리량에 중요합니다.
Proximity matters to Throughput
산소 호흡과 같은 문제
Problems like breathing Oxygen in
폐를 통해 공기 밖으로 빠져나감
Pulled out of air via Lungs
혈류로 밀어 넣어 뇌, 기관 및 사지로 전달
Pushed into Bloodstream and Delivered to Brain, Organs, and Limbs
혈전 감소로 혈류 증가
Increased blood flow with reduced clots
- 아스피린과 알코올 Aspirin and Alcohol
- 운동과 유산소 Exercise and Cardio
Cardio 시스템과 같은 슈퍼컴퓨터 미들웨어? 문제를 흡입하여 유용한 에너지 가치 처리량으로 전환
Supercomputer middleware like Cardio system? Problems breathed in and turned into useful Energy Value Throughput
잠금 및 세마포어 종류가 필요한 공유 데이터는 가능하면 처리량 증가 가능성을 피하기 위해 혈전과 같은 종류입니다.
Shared data that requires locks and semaphores kind of like clots, if possible to avoid have the potential to increase Throughput
자가 치유 네트워크 및 동적 경로 재지정에 대한 생각
Thoughts around self healing networks and dynamic rerouting
거대한 자물쇠, 처리하지 않으면 처리량을 제한할 가능성이 있는 교착 상태와 같은 암 및 대량?
Cancer and Masses like giant locks, deadlocks that have the potential to limit throughput if not handled?
문제가 해결되는 방식, 답이 중요합니다. 문제 대 솔루션은 시스템 설계 방식에 따라 교착 상태 또는 교착 상태 감소로 이어질 가능성이 있습니다. 덜 밀접하게 결합된 데이터 종속성은 더 자유롭게 이동할 수 있는 능력으로 이어질 수 있습니다.
How Problems are Solved, Answered matters. Problem to Solution has potential to lead to deadlocks, or less deadlocks depending on how a system is designed. Less tightly coupled data dependencies can lead to more ability to move freely.
Event Driven Architectures, Streams, Publish Subscribe System은 자율 운영을 유지할 가능성이 있습니다. 근접성을 고려한 로드 밸런싱은 강력할 수 있습니다. 마이크로서비스는 다양한 앱이 사용할 수 있는 방식으로 추출되고 수평으로 확장된 여러 시스템에서 사용되는 라이브러리 또는 시스템을 사용할 수 있습니다. 확장 가능한 강력한 방식으로 시스템 수준에서 DRY를 더 많이 허용합니다.
Event Driven Architectures, Streams, Publish Subscribe Systems have the potential for maintaining autonomous operation. Load balancing that takes into account proximity can be Powerful. Microservices can take a library or system that is used by multiple systems extracted and scaled horizontally in a way that many different apps can use. Allows for DRY more at a system level in powerful way that can be scaled.
https://en.wikipedia.org/wiki/Load_balancing_(computing)
마이크로서비스 아키텍처는 또한 이상적이지 않은 방식으로 상호 의존성을 높일 가능성이 있습니다. 서비스 B, C 및 D가 의존하는 하나의 MicroserviceA. MicroserviceA를 업데이트하려면 ServiceB, ServiceC 및 ServiceD가 ServiceB만 수정할 것으로 예상되는 경우에도 여전히 작동하는지 테스트하고 검증해야 합니다. 신뢰는 잠재적으로 비즈니스에 이상적이지 않은 방식으로 표면적을 높일 수 있습니다.
Microservice Architectures also have potential for turning up interdependencies possibly in non ideal ways. One MicroserviceA that service B, C, and D rely upon. Updating MicroserviceA requires testing and validating ServiceB, ServiceC, and ServiceD still work even if the change is only expected to modify ServiceB. Reliance can turn up surface area in potentially non ideal ways for business.
다른 환경은 정상적이고 강력하며 복잡성에 대한 추가 비용을 발생시킵니다. MicroserviceA가 업데이트되었지만 프로덕션에서 MicroserviceA(버전-1)는 그대로 둡니다. 이제 ServiceB를 테스트할 수 있으며 다른 시스템은 계속해서 MicroserviceA(버전 1)에 의존할 수 있습니다. 시간이 지남에 따라 유지 관리하기 어려울 수있는 코드베이스의 격차와 비 이상적 분기가 발생할 가능성이 있습니다.
Different Environments is normal and is powerful, does create extra costs around complexity. MicroserviceA updated but leaves MicroserviceA(version-1) in production. Now ServiceB can be tested and other systems can continue relying on MicroserviceA(version-1). Though that has the potential for creating a gap and more potential non ideal branching of codebases that might be hard to maintain over time.
복잡성은 시간이 지남에 따라 증가하며 미리 제한하는 것이 강력합니다. 교착 상태 가능성이 적은 방식으로 시스템을 설계할 수 있는 경우 처리량 증가 가능성 및 버그 가능성 감소 가능성이 있습니다(가끔 생산에 한 번만 나타나는 일시적인 드문 경우도 가능).
Complexity grows over time, limiting in advance is powerful. If system can be designed in ways with less potential for Deadlocks, potential for increased Throughput and potentially less bugs (possibly even transient rare case ones that only show up in production every once in a while).
유한 상태 기계는 안전 및 안전하지 않은 상태에 대한 가능성이 있습니다.
Finite State Machines have potential for Safe and Unsafe states
안전 상태를 높이고 안전하지 않은 상태를 줄이면서 시스템을 설계할 수 있습니다.
Systems can be design with increased Safe States and Reduced Unsafe States
My Tech Blog 