Downloaded 464 times
Uploaded byAraf Karsh Hamid
Microservices Part 3 Service Mesh and Kafka
The document discusses distributed computing, focusing on microservices architecture, including design patterns such as the sidecar and service mesh. It details the differences between monolithic and microservices systems, as well as the event stream handling using Apache Kafka. Key concepts include scalability, service design, and the importance of a robust communication infrastructure for microservices.
More Related Content
Similar to Microservices Part 3 Service Mesh and Kafka
Microservices Part 3 Service Mesh and Kafka
- 1. Araf Karsh Hamid,Co-Founder / CTO, MetaMagic Global Inc., NJ, USA Part 3/4 : Distributed Computing, Sidecar Design Pattern & Security Part 1 : Microservices Architecture Part 2 : Event Storming and Saga
- 2. 15-04-2018 2 Agenda 1. MicroServices Characteristics 2. Micro Services System Design Model 3. Monolithic Vs. Micro Services Architecture 4. SOA Vs. Micro Services Architecture 5. App Scalability Based on Micro Services 6. Design Patterns Micro Services Introduction1 1. Eight fallacies of Distributed Computing 2. Service Mesh 3. Sidecar Design Pattern 4. Service Mesh – Sidecar Design Pattern 5. Service Mesh – Per Host Design Pattern 6. Service Mesh Software Features 7. Service Mesh – Traffic Control 8. Service Mesh Open Source Infrastructures Service Mesh2 1. Kafka Features 2. Kafka Topic & Durability 3. Kafka Data Structure 4. Kafka Operations 5. Kafka Performance 6. Kafka Case Study Apache Kafka3
- 3. Micro Services Characteristics 3 1.1 ByJames Lewis and Martin Fowler We can scale our operation independently, maintain unparalleled system availability, and introduce new services quickly without the need for massive reconfiguration. — Werner Vogels, CTO, Amazon Web Services Modularity ... is to a technological economy what the division of labor is to a manufacturing one. W. Brian Arthur, author of e Nature of Technology The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Alan Kay, 1998 email to the Squeak-dev list Components via Services Organized around Business Capabilities Products NOT Projects Smart Endpoints & Dumb Pipes Decentralized Governance & Data Management Infrastructure Automation Design for Failure Evolutionary Design 15-04-2018
- 4. Micro Services SystemDesign Model Service (Micro) Process & Tools CultureOrganization Solution (Macro) 15-04-2018 4 Service: Focuses on a specific Business Capability Process & Tools: Development, Code Deployment, Maintenance and Product Management Culture: A Shared set of values, beliefs by everyone. Ubiquitous Language in DDD is an important aspect of Culture. Organization: Structure, Direction of Authority, Granularity, Composition of Teams. Solution: Coordinate all inputs and outputs of multiple services. Macro level view of the system allows the designer to focus more on desirable system behavior. 1.2 The very first step of a service design process is to design the process itself. Marc Stickdorn, author of This is Service Design Thinking
- 5. 15-04-20185 Monolithic vs. MicroServices Example Traditional Monolithic App using Single Technology Stack Micro Services with Multiple Technology Stack Existing aPaaS vendors creates Monolithic Apps. This 3 tier model is obsolete now. Source: Gartner Market Guide for Application Platforms Nov 23, 2016 Event Stream API Gateway (Zuul Edge Server) Load Balancer (Ribbon) Circuit Breaker (Hysterix) Service Discovery (Eureka) Load Balancer (Ribbon) Circuit Breaker (Hysterix) Load Balancer (Ribbon) Circuit Breaker (Hysterix) UI Layer Web Services Business Logic Database Layer Micro Service 4 EE 7 Catalogue UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1.3 UI Layer WS BL DL Database ShoppingCart Order Customer Catalogue
- 6. 15-04-2018 6 SOA vs. MicroServices Example Traditional Monolithic App with SOA Micro Services with Multiple Technology Stack Event Stream UI Layer Web Services Business Logic Database Layer Micro Service 1 Customer SE 8 UI Layer Web Services Business Logic Database Layer Micro Service 3 ShoppingCart UI Layer Web Services Business Logic Database Layer Micro Service 2 Order 1.4 API Gateway Load Balancer Circuit Breaker Service Discovery Load Balancer Circuit Breaker Load Balancer Circuit Breaker UI Layer Database ShoppingCart Order Customer Catalogue Enterprise Service Bus Messaging REST / SOAP HTTP MOM JMS ODBC / JDBC Translation Web Services XML WSDL Addressing Security Registry Management Producers Shared Database Consumers3rd Party Apps Smart Pipes Lot of Business logic resides in the Pipe
- 7. Scale Cube andMicro Services 15-04-2018 7 1. Y Axis Scaling – Functional Decomposition : Business Function as a Service 2. Z Axis Scaling – Database Partitioning : Avoid locks by Database Sharding 3. X Axis Scaling – Cloning of Individual Services for Specific Service Scalability 1.5
- 8. 15-04-2018 8 Design Patterns Single Component Pattern AComponent shall do ONLY one thing, But do it in FULL. Single Responsibility Principle By DeMarco : Structured Analysis & System Specification (Yourdon, New York, 1979) Let-It-Crash Pattern Prefer a FULL component restart to complex internal failure handling. Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003) Popularized by Netflix Chaos Monkey. Erlang Philosophy Saga Pattern Divide long-lived distributed transactions into quick local ones with compensating actions for recovery. Pet Helland: Life Beyond Distributed Transactions CIDR 2007 1.6
- 9. Summary – MicroServices Intro 15-04-2018 9 Microservices Benefits 1. Robust 2. Scalable 3. Testable (Local) 4. Easy to Change and Replace 5. Easy to Deploy 6. Technology Agnostic Service Oriented Architecture Micro Service Martin Fowler – Micro Services Architecture https://martinfowler.com/articles/microservices.html Dzone – SOA vs Micro Services : https://dzone.com/articles/microservices-vs-soa-2 1.7
- 10. 15-04-2018 10 1. EightFallacies of Distributed Computing 2. Service Mesh 3. Sidecar Design Pattern 4. Service Mesh – Sidecar Design Pattern 5. Service Mesh – Per Host Design Pattern 6. Service Mesh Software Features 7. Service Mesh – Traffic Control 8. Service Mesh Open Source Infrastructures Service Mesh2 Microservices Communication Infrastructure
- 11. 8 Fallacies ofDistributed Computing 15-04-2018 11 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. Transport cost is zero. 5. The network is secure. 6. Topology doesn't change. 7. There is one administrator. 8. The network is homogeneous. 2.1
- 12. Service Mesh 15-04-2018 12 Aservice mesh is a dedicated infrastructure layer for making service- to-service communication 1. Safe 2. Reliable 3. Loosely Coupled 2.2
- 13. Sidecar Design Pattern 15-04-201813 Source: https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar • The sidecar is attached to a parent application and provides supporting features for the application. • The sidecar also shares the same lifecycle as the parent application, being created and retired alongside the parent. This pattern is named Sidecar because it resembles a sidecar attached to a motorcycle Context and Problem Applications and services often require related functionality, such as monitoring, logging, configuration, and networking services. These peripheral tasks can be implemented as separate components or services. Solution Primary App Core Functionality • Proxy to Remote Services • Logging • Configuration Sidecar Host 2.3
- 14. Service Mesh –Sidecar Design Pattern 15-04-2018 14 2.4 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process1Process2 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. Service Discovery Calls Service Mesh Calls Customer Microservice Application Localhost calls http://localhost/order/processOrder Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/payment/processPayment Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane
- 15. 15-04-2018 15 Service Mesh– Per Host Design Pattern2.5 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. DataPlane Service Discovery Calls Router Network Stack Load BalancerCircuit Breaker Service Discovery Service Mesh Application Localhost calls http://localhost/order/processOrder Customer Microservice UI Layer Web Services Business Logic Order Microservice UI Layer Web Services Business Logic Payment Microservice UI Layer Web Services Business Logic Host
- 16. Service Mesh SoftwareFeatures 15-04-2018 16 2.6 • Load Balancing • Latency based Routing • Service Discovery • Access Control • Per Request Routing • Shadowing • Fault Injection Traffic Controls • Request Volumes • Success Rates • Latency Logs • Distributed Tracing Observability • Health Checks • Timeouts • Circuit Breakers • Retries Reliability
- 17. Service Mesh –Traffic Control 15-04-2018 17 API Gateway End User Business Logic Service Mesh Sidecar Customer Service Mesh Control Plane Admin Traffic Rules Traffic Control rules can be applied for • different Microservices versions • Re Routing the request to debugging system to analyze the problem in real time. • Smooth migration path 2.7 Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v1.0 Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v2.0 Service Cluster
- 18. Service Mesh –Open Source Infrastructures 15-04-2018 18 LinkerDIstio 2.8 https://istio.io/docs/concepts/what-is-istio/overview.html. https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
- 19. Libraries 15-04-2018 19 Karyon +HTTP/JSON or RxNetty RPC + Eureka + Hysterix + Ribbon + Zuul HTTP/JSON + SmartStack + ZooKeeper + Charon / Dyno Finagle + Thrift + ZooKeeper + Zipkin Stubby + GSLB + GFE + Dapper 2.8
- 20.
- 21. 4/15/2018 21 1. KafkaFeatures 1. Core Concepts 2. Producers, Consumers and Consumer Groups 3. Kafka API 4. Traditional Queue / Pub-Sub Vs. Kafka 2. Kafka Topic & Durability 1. Anatomy of Topic 2. Partition Log Segment 3. Cluster – Topic and Partitions 4. Record Commit Process 5. Consumer Access & Retention Policy 6. Replication Apache Kafka3 3. Kafka Records / Messages 1. Kafka Record v1 2. Kafka Record v2 3. Kafka Record Batch 4. Kafka Operations 1. Kafka Setup 2. Kafka Producer / Consumer API 3. Protocol Buffer v3.0 5. Kafka Performance 1. LinkedIn Kafka Cluster 2. Uber Kafka Cluster Apache Kafka
- 22. Kafka Core Concepts 15-04-201822 1 3.1 Publish & Subscribe Read and write streams of data like a messaging system Process Write scalable stream processing apps that react to events in real- time. Store Store streams of data safely in a distributed, replicated, fault tolerant cluster.
- 23. 15-04-2018 23 Producers, Consumersand Consumer Groups • Producers publish data to the topics of their choice. • The producer is responsible for choosing which record to assign to which partition within the topic. • This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the record). Producers • Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. Consumer instances can be in separate processes or on separate machines. • If all the consumer instances have the same consumer group, then the records will effectively be load balanced over the consumer instances. • If all the consumer instances have different consumer groups, then each record will be broadcast to all the consumer processes. Consumers Source: https://kafka.apache.org/documentation/#api 2 3.1
- 24. Kafka APIs 15-04-2018 24 Source: https://kafka.apache.org/documentation/#gettingStarted • The Producer API allows an application to publish a stream of records to one or more Kafka topics. • The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them. • The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams. • The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table. 3 3.1
- 25. Traditional Queue /Pub-Sub Vs. Kafka 15-04-2018 25 0 1 2 3 4 5 6 7 8 9 8 7 9 Consumer 1 Consumer 2 Consumer 3 Queues Data Data can be partitioned for scalability for parallel processing by same type of consumers Pros: Cons: Queues are not multi subscribers. Once a Consumer reads the data, its gone from the queue. Ordering of records will be lost in asynchronous parallel processing. 0 1 2 3 4 5 6 7 8 9 9 9 9 Consumer 1 Consumer 2 Consumer 3 Pub – Sub Data Multiple subscribers can get the same data.Pros: Scaling is difficult as every message goes to every subscriber. Cons: Kafka generalizes these two concepts. As with a queue the consumer group allows you to divide up processing over a collection of processes (the members of the consumer group). As with publish-subscribe, Kafka allows you to broadcast messages to multiple consumer groups. 4 3.1
- 26. 15-04-2018 26 Kafka Topicand Durability 1. Anatomy of Topic 2. Partition Log Segment 3. Cluster – Topic and Partitions 4. Record Commit Process 5. Consumer Access & Retention Policy 6. Replication
- 27. Anatomy of aTopic 15-04-2018 27 Source : https://kafka.apache.org/intro • A Topic is a category or feed name to which records are published. • Topics in Kafka are always multi subscriber. • That is, a Topic can have zero, one, or many consumers that subscribe to the data written to it. • Each Partition is an ordered, immutable sequence of records that is continually appended to—a structured commit log. • A Partition is nothing but a directory of Log Files • The records in the partitions are each assigned a sequential id number called the offset that uniquely identifies each record within the partition. 1 3.2
- 28. 15-04-2018 28 Partition LogSegment • Partition (Kafka’s Storage unit) is Directory of Log Files. • A partition cannot be split across multiple brokers or even multiple disks • Partitions are split into Segments • Segments are two files: 000.log & 000.index • Segments are named by their base offset. The base offset of a segment is an offset greater than offsets in previous segments and less than or equal to offsets in that segment. • Indexes store offsets relative to its segments base offset • Indexes map each offset to their message position in the log and they are used to look up messages. • Purging of data is based on oldest segment and one segment at a time. 2 3.2 0 1 2 3 4 5 6 7 8 9 Partition Data 6 3 0 Segment 0 Segment 3 Segment 6 9 Segment 9 - Active $ tree kafka-logs | head -n 6 kafka-logs |──── SigmaHawk-2 | |──── 00000000006109871597.index | |──── 00000000006109871597.log | |──── 00000000007306321253.index | |──── 00000000007306321253.log Topic / Partition Segment 1 Segment 2 Rel.Offset, Position Offset, Position, Size, Payload 0000.index 0000.log 0 0 0 0 7 ABCDEFG 1 7 1 7 4 ABCD 2 11 2 11 9 ABCDEFGIJ 4 Bytes 4 Bytes
- 29. 15-04-2018 29 Kafka Cluster– Topics & Partitions • The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Source : https://kafka.apache.org/intro 3 3.2 Broker 1 Leader Broker 2 Follower Broker 3 Follower Broker 4 Follower Broker 5 Leader Partition 1 Partition 0 Topic ABC • Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster. • Each partition has one server which acts as the "leader" and zero or more servers which act as "followers".
- 30. 15-04-2018 30 Record Commit Process 4 3.2 Broker1 Leader Topic 1 Broker 2 Follower Producer Consumer 2 2 Commit 3 ack • Each partition is replicated across a configurable number of servers for fault tolerance. • The leader handles all read and write requests for the partition while the followers passively replicate the leader. • If the leader fails, one of the followers will automatically become the new leader.1 Message with Offset 4 777743 Broker 3 Follower Data Durability From Kafka v0.8.0 onwards acks Acknowledgement Description 0 If set to zero then the producer will NOT wait for any acknowledgment from the server at all. The record will be immediately added to the socket buffer and considered sent. No guarantee can be made that the server has received the record in this case, and the retries configuration will not take effect (as the client won't generally know of any failures). The offset given back for each record will always be set to -1. 1 This will mean the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers. In this case should the leader fail immediately after acknowledging the record but before the followers have replicated it then the record will be lost. All / -1 This means the leader will wait for the full set of in-sync replicas to acknowledge the record. This guarantees that the record will not be lost as long as at least one in-sync replica remains alive. This is the strongest available guarantee. This is equivalent to the acks=-1 setting. Source: https://kafka.apache.org/documentation/#topicconfigs acks Steps 0 1 1 1,3 -1 1,2,3 Producer Configuration
- 31. Consumer Access &Data Retention 15-04-2018 31 Source : https://kafka.apache.org/intro • For example, if the retention policy is set to 2 days, then for the two days after a record is published, it is available for consumption, after which it will be discarded to free up space. • The Kafka cluster retains all published records—whether or not they have been consumed—using a configurable retention period • Kafka's performance is effectively constant with respect to data size so storing data for a long time is not a problem. • Only metadata retained on a per-consumer basis is the offset or position of that consumer in the log. This offset is controlled by the consumer: normally a consumer will advance its offset linearly as it reads records, but, in fact, since the position is controlled by the consumer it can consume records in any order it likes. 5 3.2 777743 777742 777741 777740 777739 777738 777737 777736 Producer Consumer Consumer Consumer • Producers Push Data • Consumers Poll Data Writes Reads Offset=37 Offset=38 Offset=41
- 32. 15-04-2018 32 Replication 6 3.2 m1 m2 m3 L(A) m1 m2 F(B) m1 F(C)ISR= (A, B, C) Leader A commits Message m1. Message m2 & m3 not yet committed. 1 m1 m2 F(C) m1 m2 L(B) m1 m2 m3 L(A) ISR = (B,C) A fails and B is the new Leader. B commits m22 m1 m2 m3 L(A) m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 ISR = (B,C) B commits new messages m4 and m5 3 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 F(A) ISR = (A, B,C) A comes back, restores to last commit and catches up to latest messages. 4 m1 m2 L(B) m4 m5 m1 m2 F(C) m4 m5 m1 m2 F(A) m4 m5 ISR – In-sync Replica • Instead of majority vote, Kafka dynamically maintains a set of in-sync replicas (ISR) that are caught-up to the leader. • Only members of this set are eligible for election as leader. • A write to a Kafka partition is not considered committed until all in-sync replicas have received the write. • This ISR set is persisted to ZooKeeper whenever it changes. Because of this, any replica in the ISR is eligible to be elected leader.
- 33. 15-04-2018 33 Kafka DataStructures 1. Kafka Record v1 2. Kafka Record v2 3. Kafka Record Batch
- 34. Kafka Record /Message Structure 15-04-2018 34 Magic AttrCRC int64 int32 int8 Timestamp Header Key (Variable Length) Value (Variable Length) Payload v1 (Supported since 0.10.0) Field Description CRC The CRC is the CRC32 of the remainder of the message bytes. This is used to check the integrity of the message on the broker and consumer. Magic Byte This is a version id used to allow backwards compatible evolution of the message binary format. The current value is 2. Attributes Bit 0-2 Compression Codec 0 No Compression 1 Gzip Compression 2 Snappy Compression Bit 3 Timestamp Type: 0 for Create Time Stamp, 1 for Log Append Time Stamp Bit. 4 is Transactional (0 means Transactional) Bit 5 is Control Batch (0 means Control Batch) Bit >5. Un used Timestamp This is the timestamp of the message. The timestamp type is indicated in the attributes. Unit is milliseconds since beginning of the epoch (midnight Jan 1, 1970 (UTC)). Key The key is an optional message key that was used for partition assignment. The key can be null. Value The value is the actual message contents as an opaque byte array. Kafka supports recursive messages in which case this may itself contain a message set. The message can be null. int8 Source: https://kafka.apache.org/documentation/#messages 1 3.3
- 35. Kafka Record Structure 35 v2(Supported since 0.11.0) Length (varint) Attr int8 Timestamp Delta (varint) Offset Delta (varint) Key Length (varint) Key (varint) Value Length (varint) Value (varint) Headers (Header Array) Header Key Length (varint) Header Key (varint) Header Value Length (varint) Header Value (varint) Header Record • In Kafka 0.11, the structure of the 'Message Set' and 'Message' were significantly changed. • A 'Message Set' is now called a 'Record Batch', which contains one or more 'Records' (and not 'Messages'). • The recursive nature of the previous versions of the message format was eliminated in favor of a flat structure. • When compression is enabled, the Record Batch header remains uncompressed, but the Records are compressed together. • Multiple fields in the 'Record' are varint encoded, which leads to significant space savings for larger batches. 2 3.3
- 36. Kafka Record BatchStructure 36v2 (Supported since 0.11.0) Field Description First Offset Denotes the first offset in the Record Batch. The 'offset Delta' of each Record in the batch would be be computed relative to this First Offset. Partition Leader Epoch this is set by the broker upon receipt of a produce request and is used to ensure no loss of data when there are leader changes with log truncation. Attributes The fifth lowest bit indicates whether the Record Batch is part of a transaction or not. 0 indicates that the Record Batch is not transactional, while 1 indicates that it is. (since 0.11.0.0) Last Offset Delta The offset of the last message in the Record Batch. This is used by the broker to ensure correct behavior even when Records within a batch are compacted out. First Timestamp The timestamp of the first Record in the batch. The timestamp of each Record in the Record Batch is its 'Timestamp Delta' + 'First Timestamp'. Max Timestamp The timestamp of the last Record in the batch. This is used by the broker to ensure the correct behavior even when Records within the batch are compacted out. Producer ID This is the broker assigned producer Id received by the 'Init Producer Id' request. Producer Epoch This is the broker assigned producer Epoch received by the 'Init Producer Id' request. First Sequence This is the producer assigned sequence number which is used by the broker to de-duplicate messages. The sequence number for each Record in the Record Batch is its Offset Delta + First Sequence. First Offset int64 Length int32 Partition Leader Epoch int32 Magic int8 CRC int32 Attr int16 Last offset Delta int32 First Timestamp int64 Max Timestamp int64 Producer Epoch int16 Producer ID int64 First Sequence int32 Records (Record Array) 3 3.3
- 37.
- 38. Kafka Quick Setup& Demo 15-04-2018 38 1. install the most recent version from Kafka download page 2. Extract the binaries into a /…./Softwares/kafka folder. For the current version it's kafka_2.11-1.0.0.0. 3. Change your current directory to point to the new folder. 4. Start the Zookeeper server by executing the command: bin/zookeeper-server-start.sh config/zookeeper.properties. 5. Start the Kafka server by executing the command: bin/kafka-server-start.sh config/server.properties. 6. Create a Test topic that you can use for testing: bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic KafkaSigmaTest 7. Start a simple console Consumer that can consume messages published to a given topic, such as KafkaSigmaTest: bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic KafkaSigmaTest --from-beginning. 8. Start up a simple Producer console that can publish messages to the test topic: bin/kafka-console-producer.sh --broker-list localhost:9092 --topic KafkaSigmaTest 9. Try typing one or two messages into the producer console. Your messages should show in the consumer console.
- 39. Kafka Producer (Java) 15-04-201839 Kafka Producer Configuration Kafka Producer Synchronous
- 40. Kafka Consumer (Java) 15-04-201840 Kafka Consumer Configuration Kafka Consumer
- 41.
- 42.
- 43. ProtoBuf – Objectto JSON & JSON to Object 15-04-2018 43 Object to JSON JSON to Object
- 44.
- 45. LinkedIn Kafka Cluster 15-04-201845 Brokers60 Partitions50K Messages / Second800K MB / Second inbound300 MB / Second Outbound1024 The tuning looks fairly aggressive, but all of the brokers in that cluster have a 90% GC pause time of about 21ms, and they’re doing less than 1 young GC per second.
- 46. Uber Kafka Cluster 15-04-201846 Topics10K+ Events / Second11M Petabyte of Data1PB+ https://docs.confluent.io/current/kafka/deployment.html
- 47. References 15-04-2018 47 1. Linkerd+ Kubernetes 2. Installing Istio 3. Tim Perrett: Envoy with Nomad and Consul 4. NGINX Fabric Model 5. William Morgan - Linkerd: 6. Christian Posta – Envoy/Istio 7. Matt Klein – Envoy: 8. Kelsey Hightower – Istio 9. https://www.youtube.com/watch?v=s4qasWn_mFc
- 48. 15-04-2018 48 Thank you ArafKarsh Hamid : Co-Founder / CTO MetaMagic Global Inc. NJ, USA araf.karsh@metamagic.in | araf.karsh@gmail.com USA: +1 (973) 969-2921 India: +91.999.545.8627 Skype / LinkedIn / Twitter / Slideshare : arafkarsh http://www.slideshare.net/arafkarsh https://www.linkedin.com/in/arafkarsh/ A Micro Service will have its own Code Pipeline for build and deployment functionalities and it’s scope will be defined by the Bounded Context focusing on the Business Capabilities and the interoperability between Micro Services will be achieved using (asynchronous) message based communication.
- 49. 4/15/2018 49 1. JSONWeb token JSON Web Token 4
- 50. JSON Web Tokens: http://jwt.io JSON Web Tokens (JWT) Pronounced “jot”, are a standard since the information they carry is transmitted via JSON. We can read more about the draft, but that explanation isn’t the most pretty to look at. JSON Web Tokens work across different programming languages: JWTs work in .NET, Python, Node.JS, Java, PHP, Ruby, Go, JavaScript, and Haskell. So you can see that these can be used in many different scenarios. JWTs are self-contained: They will carry all the information necessary within itself. This means that a JWT will be able to transmit basic information about itself, a payload (usually user information), and a signature. JWTs can be passed around easily: Since JWTs are self-contained, they are perfectly used inside an HTTP header when authenticating an API. You can also pass it through the URL. 15 April 2018 50 Header Payload Secret JSON Web Signature JWS: RFC 7515 JSON Web Encryption JWE : RFC 7516 JSON Web Key JWK : RFC 7517 JSON Web Algorithms JWA : RFC 7518 JSON Web Token JWT: RFC 7519
- 51. Authentication Traditional Way 15April 2018 51 The Problems with Server Based Authentication. A few major problems arose with this method of authentication. Sessions: Every time a user is authenticated, the server will need to create a record somewhere on our server. This is usually done in memory and when there are many users authenticating, the overhead on your server increases. Scalability: Since sessions are stored in memory, this provides problems with scalability. As our cloud providers start replicating servers to handle application load, having vital information in session memory will limit our ability to scale. CORS: As we want to expand our application to let our data be used across multiple mobile devices, we have to worry about cross-origin resource sharing (CORS). When using AJAX calls to grab resources from another domain (mobile to our API server), we could run into problems with forbidden requests. CSRF: We will also have protection against cross-site request forgery (CSRF). Users are susceptible to CSRF attacks since they can already be authenticated with say a banking site and this could be taken advantage of when visiting other sites. With these problems, scalability being the main one, it made sense to try a different approach. Source: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- 52. JSON Web Token:Stateless Architecture 15 April 2018 52 How it Works Token based authentication is stateless. We are not storing any information about our user on the server or in a session. 1. User Requests Access with Username / Password 2. Application validates credentials 3. Application provides a signed token to the client 4. Client stores that token and sends it along with every request 5. Server verifies token and responds with data Every single request will require the token. This token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests. We will also need to set our server to accept requests from all domains using Access-Control-Allow- Origin: *. What’s interesting about designating * in the ACAO header is that it does not allow requests to supply credentials like HTTP authentication, client-side SSL certificates, or cookies. Source: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- 53. JSON Web Token: Benefits 53 Stateless and Scalable Tokens stored on client side. Completely stateless, and ready to be scaled. Our load balancers are able to pass a user along to any of our servers since there is no state or session information anywhere. Security The token, not a cookie, is sent on every request and since there is no cookie being sent, this helps to prevent CSRF attacks. Even if your specific implementation stores the token within a cookie on the client side, the cookie is merely a storage mechanism instead of an authentication one. There is no session based information to manipulate since we don’t have a session! Extensibility (Friend of A Friend and Permissions) Tokens will allow us to build applications that share permissions with another. For example, we have linked random social accounts to our major ones like Facebook or Twitter. Multiple Platforms and Domains When the application and service expands, we will need to be providing access to all sorts of devices and applications (since the app will most definitely become popular!). Having the App API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application. Standards Based Source: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- 54. JSON Web Token: Anatomy 54Header Payload Secret Header The header carries 2 parts: 1. declaring the type, which is JWT 2. the hashing algorithm to use (HMAC SHA256 in this case) Payload The payload will carry the bulk of our JWT, also called the JWT Claims. This is where we will put the information that we want to transmit and other information about our token. Secret This signature is made up of a hash of the following components: 1. The header 2. The payload 3. Secret The secret is the signature held by the server. This is the way that our server will be able to verify existing tokens and sign new ones. This gives us the final part of our JWT. eyJhbGcioiJI---.eyJpc3Mioi---.03f32998---
- 55. JSON Web Token: Anatomy – The Claims 15 April 2018 55 Registered Claims Claims that are not mandatory whose names are reserved for us. These include: • iss: The issuer of the token • sub: The subject of the token • aud: The audience of the token • exp: This will probably be the registered claim most often used. This will define the expiration in Numeric Date value. The expiration MUST be after the current date/time. • nbf: Defines the time before which the JWT MUST NOT be accepted for processing • iat: The time the JWT was issued. Can be used to determine the age of the JWT • jti: Unique identifier for the JWT. Can be used to prevent the JWT from being replayed. This is helpful for a one time use token. Public Claims These are the claims that we create ourselves like user name, information, and other important information. Private Claims A producer and consumer may agree to use claim names that are private. These are subject to collision, so use them with caution. Source: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- 56.
Editor's Notes
- #6 https://dzone.com/articles/microservices-vs-soa-2
- #7 https://dzone.com/articles/microservices-vs-soa-2
- #9 ACID (atomicity, consistency, isolation, and durability) BASE is a family of styles that include basic availability, soft state, and eventual consistency
- #13 https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
- #15 https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
- #19 https://www.envoyproxy.io/docs/envoy/latest/intro/what_is_envoy
- #20 https://twitter.github.io/finagle/ https://medium.com/airbnb-engineering/smartstack-service-discovery-in-the-cloud-4b8a080de619
- #29 The index file is made up of 8 byte entries, 4 bytes to store the offset relative to the base offset and 4 bytes to store the position. The offset is relative to the base offset so that only 4 bytes is needed to store the offset. For example: let’s say the base offset is 10000000000000000000, rather than having to store subsequent offsets 10000000000000000001 and 10000000000000000002 they are just 1 and 2. Kafka wraps compressed messages together Producers sending compressed messages will compress the batch together and send it as the payload of a wrapped message. And as before, the data on disk is exactly the same as what the broker receives from the producer over the network and sends to its consumers. https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026
- #31 Durability - the ability to withstand wear, pressure, or damage.
- #35 https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026 https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-Messagesets
- #36 https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026 https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-Messagesets
- #37 https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026 https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol#AGuideToTheKafkaProtocol-Messagesets
- #46 https://docs.confluent.io/current/kafka/deployment.html
- #47 https://docs.confluent.io/current/kafka/deployment.html
- #51 http://jwt.io https://scotch.io/tutorials/the-anatomy-of-a-json-web-token#what-does-a-jwt-look-like? https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ https://github.com/jwtk/jjwt JSON Web Token : RFC 7519 : https://tools.ietf.org/html/rfc7519 JSON Web Signature : RFC 7515 : https://tools.ietf.org/html/rfc7515 JSON Web Encryption : RFC 7516 : https://tools.ietf.org/html/rfc7516 JSON Web Key : RFC 7517 : https://tools.ietf.org/html/rfc7517 JSON Web Algorithms : RFC 7518 : https://tools.ietf.org/html/rfc7518
- #52 https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- #53 https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- #54 https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
- #55 http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication http://tools.ietf.org/html/draft-jones-json-web-token-05 https://stormpath.com/blog/jjwt-how-it-works-why/ https://github.com/jwtk/jjwt https://docs.stormpath.com/java/servlet-plugin/
- #56 Security Issues http://jwt.io https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/ https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ https://github.com/jwtk/jjwt/issues/20 https://stormpath.com/blog/jwt-java-create-verify/ https://github.com/jwtk/jjwt https://bitbucket.org/b_c/jose4j/wiki/04-01-15-Transparency CSRF https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet