List
- Postman
- Paw https://paw.cloud/
- soapUI
- HTTPie
- Postwoman
- RESTer
- RESTClient
- HttpRequester
Ref
- https://alternativeto.net/software/postman/
collectd : cpu, memory, hdd 수집 데몬
ganglia : 분산형 모니터링 시스템
cacti : 네트워크 snmp
http://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html
scribe : c++, facebook legacy
flume : apache
fluentd : ruby, c
log stash : elastic search
kibana
storm
ElasticSearch
Nagios
https://sensuapp.org/
Prometheus
이걸 뭐라고 하는데.. 프로비저닝은 아니고
puppet
ansible
chef
salt
https://www.terraform.io/
capistrano
https://github.com/capistrano/capistrano
Docker
KVM
…
Vagrant
pact, pacto??
https://github.com/presidentbeef/brakeman
sonar
Hashicorp – https://www.consul.io/
Debugging, Tracing
https://github.com/openzipkin/zipkin
https://github.com/StackExchange/Dapper
http://opentracing.io/
Hadoop, Spark
https://varnish-cache.org/
http://www.squid-cache.org/
redis
boto3 : python용 aws sdk – 배포시 사용
zookeeper
hashicorp
https://github.com/Netflix/SimianArmy
CQRS
https://github.com/VBA-tools/VBA-JSON
https://github.com/VBA-tools/VBA-Web
VBA로 RestClient호출해야하는경우 사용하기 좋은 라이브러리
MSA는 API를 이용해 통신을 한다.
그런데…. 의존성이 생기니까 관리가 힘들다.
버전관리가 필요.
의존성이 있는 모든것을 동시배포
그냥 전체배포라고 보면 된다.
* 서비스가 작을 때 가능
* 오류가 나면 매우 난감함
* DB스키마가 변경됐을 가능성이 크기 때문에 rollback도 쉽지가 않다.
컨트롤러, 라우터 등등에서
/v1/
/v2/
이런방법으로 버전을 표시
* 버전업이 자주 발생하면?
* 헷갈리겠지
jenkins, git-tag, docker, kubernetes 등등 사용해서 해결할 수 있는 부분
해놓으면 편하긴 하겠지만… 구현자체가 복잡하다.
어떻게 배포를 해도 오류가능성이 존재하겠지만… 관리가 쉬운편이 더 낫지 않을까
적절한 방법을 골라서 정책을 정하고 지키는게 중요.
API Doc은 Hunam, Machine – 두가지 버전이 필요하다.
swagger
Hataoes
그리고 json형태의 doc???
에러로깅 방식..??
등 지원
build runtime 버전 check
의존성 api들을 모두 기록해놓는다.
depends on – (auth-1.1)
depends on – (gis-201610)
….
기록해놓은 부분은 내가 참조했 버전이 맞는지 버전만 호출해서 확인.
의존성이 있는 MS들의 test 인스턴스가 떠있거나
docker-compose, kubernetes 등으로 관리되고 있어야 가능한 부분.
아닌가.. 버전만 확인하니까 git 주소만 알아도 가능할 것 같다.
유닛테스트일수도 있는데 좀 더 강하게 빌드시 확인을 해야한다.
멱등성 관련 : http://memo.polypia.net/archives/2505
JWT참고
http://bcho.tistory.com/999
https://jwt.io/
https://blog.outsider.ne.kr/1160
Claim기반 호출
HMAC을 이용한 보안
PPK필요
JWT을 적용해서 쓴다면 대략이정도 느낌이 되면 될것같다.
gradle, maven 테스트, 배포 타이밍에 적절한 조치가 필요할 것 같다.
local에서 할 때는 auth가 제역할을 못해줄 것 같으니
auth서버도 push를 하려면 ppk(auth-ppk)가 있어야하고 ResourceProvider은 auth-ppk(public key)를 가지고 있어야한다.
종이에 그릴땐 간단해보였는데 다시보니 좀 복잡해보인다. 좀 더 간소화 필요.
rest api 사용할 때 관련있는 api의 목록을 제공한다는 컨셉
참고 :
https://spring.io/understanding/HATEOAS
https://en.wikipedia.org/wiki/HATEOAS
그런데… 근본적으로 이해가 안간다.
보통 뭔가 기술적으로 정립된것들을 보면 나도 필요하다고 생각했던 경우가 많은데
이건 왜 스는건가 의아하다
이건 도큐먼트 아닌가
기계가 알아봐야하는 도큐먼트
generated doc의 일종이 되어야 할 것 같다.
/rest/api/user
/rest/doc/user
와 같은 관계가 되야하지 않을까
일단 비관적이고
뭔소린지는 알겠는데 공감이 가지 않는다.
안쓰겠다.
호출뻑할때가 많은데
멱등성이 필요할때가 많다.
unique조건. id값은 오차가 생길 수 있지만 unique를 활용하면 어느정도 처리할 수 있지 않을까
완전히 같을수는 없고
대신에 비슷한 요청이 올 때 update가 돼 버릴 수도 있다.
이게 상관없다면 이렇게 그냥 하는것도 괜찮지 않을까
상관없는 경우도 많으니
ajax호출이나 client에서 호출하는경우에 특히 중복호출이 많으니…
async로 한다면 더 심할 수 있다.
처리소요시간에 따라 적정 딜레이가 도움이 될 수도 있겠다.
cache처리하는것처럼 dynamic하게 관리되면 될 것 같다.
응답시간이 평균 5초정도라면 3초안에 중복요청은 무시해버리는식으로
사람이 많을때 서버성능을 향상시키는데도 도움이 될 것 같다.
설계는 다음에
RPC기술인데 시리얼라이징 기능은 protocol buffer을 사용하고
gRPC는 strema 서버동작에 집중되어 있다.
아쉬운점은 protocol buffer에서의 아쉬운점 그대로다.
protocol buffer에 너무 의존적이 된다.
restful/json/bson/xml처럼 프로토콜만 맞추면 뭘 써도 되는 그런 라이브러리와는 다르다.
protocol buffer의존성에서 좀 벗어나서 thrift를 사용할 수 있게 변경하려는 것 같은데
다른것들도 적용이 되려나 모르겠다.
매핑지옥이 시작된다.
API가 실행될 때 마다 리플렉션을 사용하기는 싫고
몇몇 해결방안으로 제시된 것들을 보면
같이 쓰기 썩 좋지는 않다. 매핑노가다나 리플렉션 매핑을 좀 이용해야할 것 같다.
없다. 그냥 별도라고 봐야할 것 같다.
현재 SpringBoot를 이용하고 있는데 아직 별로 나온게 없어 보인다.
컴파일러 플러그인을 다운받는데 백신이 exe파일을 자꾸 지워버린다.
exe어쩌고 하면서 실행이 안될때 확인하자
아직 완전히 적용한것은 아니지만..
쓸만하긴한데 생태계가 완벽하지 않아서 신경쓸게 좀 많다.
MessageQueue를 이용한 비동기 RPC방식보다 나은지 잘 모르겠다.
아직 고민만 해보고 테스트는 못해봐서… 아예 안쓸지도 모르겠다.
약간 고민하게 되는데 생각보다 간단한 결론은
RPC는 내부 프로토콜로 사용 – 인프라 내부가 아닌 내부 서비스간의 통신.
APP의 API로도 사용가능.
REST API는 외부공개용.
끝.
내부 서비스간 통신
외부 공개용
ModileApp은 외부에 있지만 내부 서비스이다. API와 RPC통신
외주사가 회사 내부망에 설치한 GIS솔루션은 내부 서비스가 아니다. RESTful 방식사용
몇년째 딱 대표적인 기술이 떠오르지 않고 고만고만하게 유지되고 있다.
개인적으로 RPC가 더 편하다고 생각하는데, RestAPI가 너무 대세가 되서 인기를 잃어버려 아쉽다.
아니 먼 RestAPI 데이터를 브라우저로 봐서 뭐한다고?!?~!
지금당장 기억나는것은 이정도….
Thrift
Avro
gRPC
ProtocolBuffer
BSon
완전 RPC라고 하기는 좀 그런 시리얼라이징 기술도 넓게 보면 RPC아닐까…
아니 그냥 RPC인가? 그냥 다 포함시켰다.
아직까지는 연동 API 제공 한다고 하면 당연하다는 듯이 RestAPI를 제공한다.
API는 다양한 문제점을 가지고 있고 기술적으로 열등하기 때문에 점점 사용률이 낮아질거라고 본다.
웹기반 기술에서는 계속 사용되겠지만 MicroService가 등장하며 내부 네트워크 부하가 더 심해지는판에.. 이걸 계속써야할까?
아니
여태까지는 아키텍처/UX까지 Request후 Response를 기다리는 형태로 설계가 되었으니 RestAPI를 써도 불편한줄을 몰랐다
async환경으로 변화는… 패러다임의 변화다. 설계까지 변경된다.
변화의 조짐은 보인다.
MSA, Async, Functional Programming
이정도… 그리고 이런 트렌드가 지속/확대 된다고 봐도 될 것 같다.
왜냐? 작은조직의 효율적 개발, 클라우드환경, 늘어나는 네트워크 트래픽 등등의 상화을 봤을때 방향성이 그쪽을 향하고 있으니까…
MicroService사이의 통신을 위한 가벼운 프로토콜 + MQ(MessageQueue) 클러스터를 이용한 내부 통신채널 일원화 + Functional Programming을 통한 Async방식 개발
이 될 것이고
MQ를 이용한 Async프로그래밍을 도와주는 프레임워크이 등장하면서 RPC 사용이 활발해질 것이다.
이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…