Hi,
On Thu, Jan 9, 2014 at 2:12 AM, Jabbar Azam <[email protected]> wrote: > Hello, > > I'm trying to devise a system which resembles a bunch of micro services or > nodes. Each micro service is assigned to one or many nodes. A bunch of > micro services will be the masters receiving work requests from the REST( > spray.io) micro services and notifications from the worker micro services > for work. > > An example micro service is the security service. This will receive a case > class asking to verify a user/password combination, will talk to cassandra, > cache the information in the service(an actor) and then return the result > back to the calling actor(the REST layer). > > I want to be able to add new services and update existing services without > impacting on access to the REST layer for the users. > > I have a number of questions > > 1) If I use an akka node for each service then isn't the Actor system > going to be resource heavy? > http://doc.akka.io/docs/akka/2.3-M2/general/actor-systems.html > Are you thinking of running one JVM for each micro service? The JVM is very heavy, and you can only run a few on each server machine (depends on the hardware of course). If you need to update (restart) the services independent of each other you will most likely want to one JVM per service (or group related services that can be restarted together). You can run several actor systems in the same JVM. An ActorSystem is heavy compared to actors. A few threads and some 10MB of heap memory. Considerations when comparing one or several actor systems in the same JVM: - You don't win much isolation from several actor systems. They share the same heap (GC) anyway. - You can achieve bulk heading of threads with separate dispatchers of one actor system. - Communication between actors of different actor systems is done via the remote interface. > > 2) If I use routers then the code for each routee(worker micro service) > needs to be on most if not every node, depending on how many nodes I want > the micro service to run on. > You can use cluster node roles<http://doc.akka.io/docs/akka/2.3-M2/scala/cluster-usage.html#Node_Roles> . > Is it a good idea to have the micro services in their own node or is it > better to consolidate the micro services into one node? The drawback with > this is that separate teams can't develop their own micro services. > If you have an overall design that takes this into account it should not be a problem to develop the services separately and then package and deploy them in one ActorSystem. All three options are possible, and you have to pick the alternative that meets your needs. I would say that one JVM with several actor systems is least attractive. Regards, Patrik > The routers would only be used to create and supervise the worker micro > services; > > Can anybody see anything wrong with this system? > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
