used only for hsbc examination purpose
- A rule, which can be configured and executed for a certain rule based on features, for example, is it a suspicious login (rule2)
- A feature/variable, which can be configured and executed for a certain feature based on user data, for example, how many failed login attempts an account tried (xIllegalLogins)
- A data, which simulates and mocks data which will be used for feature computation
- support for antifraud detecting & message processing, which process messages/payloads and gives fraud alert & logs
- source code is within
- tests are under anitfraud-web/src/test; reports with coverage using maven can be generated and locate under antifraud-web/target/site/jacco-aggregate/index.html
- Kubernetes deployment file is under /Docker & /center.yaml;
- Documentation is as below mentioned, including functionality & architect docs; also some detailed tips are within code
- Resilience test has to go over aliyun and give a manual demonstration, for example it needs to shutdown pod manually and check logs and mq see the processing which hasn't been jepardized
- logical arch regarding
- a sequence diagram which demonstrates a major flow of execution
- deployment arch
- antifraud-web module, it provides messaging and web related functions, also configurations and tests are within
- antifraud-service module, it provides all antifraud related services and all regarding utils, model, etc
all tests are under antifraud-web/src/test/java/...; tests can be run in either idea or triggered by a maven build
- NOTED, to make test running locally, spring.profiles.active shall be set to dev, which is located antifraud-web/src/main/resources/application.yml
- active: dev
- FeatureTest
- RuleTest
- EnvTest, it is regarding environtment settings
- MessagingTest, it is regarding messaging send & receiving to ali-cloud.
- AntifraudTest
- testIntegration1 is an integration test in a non-message way, which can be run locally and detection will be alerted through console
- testIntegration2 is an integration test in a message way, which is sent to mq and all nodes can consume messages and do fraud detects
mocked traffics locate in this test
- this project uses surefire and jacco, in which test results will be output under antifraud-web/target/site/jacco-aggregate/index.html
- following is a test coverage report generated by jacco
it is deployed on ali-cloud ack
- it is in a mirror way to deploy ack env
- the deployment details can be viewed in either Dockerfile & center.yaml
- the system also used https://devops.aliyun.com/ in a flow to deploy the deployable
- start curl localhost:8080/antifraud/start
- stop curl localhost:8080/antifraud/stop
- status (shows how many thread is running) curl localhost:8080/antifraud/status
- enlarge (when concurrent consumers are not enough, can enlarge on the fly) curl localhost:8080/antifraud/enlarge
- check info.log using grep "cost" /home/logs/antifraud/info.log
- latency tracks is a cost stats which give milliseconds of the whole antifraud execution process
in order to run this u need to have following criteria
- jdk8
- maven
- springboot
- using a subaccount to login ack env
+ https://signin.aliyun.com/ choose to use subaccount login
+ loginname and password is -> interviewer@1712034974828389.onaliyun.com ape@1234
+ shall bind a mobile in order to login
- login url -> csnew.console.aliyun.com
- then shall able to login and see this screen below
- application nodes can be accessed through 工作负载>>无状态>>hsbc-antifraud-test
- hpa settngs are under 工作负载>>无状态>>hsbc-antifraud-test>>容器伸缩
- mq using mns, can reach through following https://mns.console.aliyun.com/region/cn-hangzhou/queue/antifraud/detail
- logs are under 运维管理>>日志中心>>应用日志, an example is shown below
certain assumptions are taken as below to simply situation or give a default solution giving this examination purpose
- assume that rule and scenario are single to single relationship
- assume single rule enough to detect fraud, otherwise it will involve flow engine which is out of the scope of this exam
- assume data which used in feature/variable computing can be mocked, otherwise db or other storage will be involved
- assume that minimal configurations to rules/features are involved, otherwise system need to be separated into two sub-sytems, 1 console for configuration and 2 running engine for execution
- assume that feature computing can be simplified
- assume that fraud notifications/alerts can be simplified through log
- assume that traffic can be sent through either local env or a node