Every process that runs on a Windows computer needs to be run under some kind of credentials. Put more simply, every process needs to be "logged on" with some account in order to run. I assumed/thought this was true of Unix/Linux processes also.
Anyway, since services represent processes, every service has to "log on" in order to be able to run. Whatever access rights and permissions apply to the account being used by a service also apply to the service as it runs.
If you open up the list of services (in Computer Management or the Services snap-in), you will see the "Log On As" column in the list of services. Most services either log on as "Local System" or "Network Service". Neither of those objects are appropriate for certain application services like SQL Server services, but the SQL Server services still must log on as some account.
That is all a service account is. It's an account used by a service that is not using the Local System or Network Service accounts. It can either be a local account or a domain account, as needed and/or appropriate. In order for services to function correctly, service accounts must be granted certain rights and permissions. If you create service accounts when installing applications that request them, they usually grant the appropriate rights and permissions when the accounts are created. Tracking down and granting the rights and permissions manually can be tedious. It's good to plan service accounts before you install applications that need them.
You may often be tempted to use an administrator account for a service account, since usually they already have the necessary rights and permissions. There are practical reasons and security reasons not to do this, which I won't go into here, but don't do it. It's also best for each application to have its own service account, rather than for all applications to use a single service account. There are many other considerations, but that should be enought to get you started.
